Sunteți pe pagina 1din 224

1

Índice General

Contenido
.......................................................................................................................................... 5
CAPITULO I ...................................................................................................................... 5
Descripción de la Organización ................................................................................................ 6
Filosofía de la Gestion ................................................................................................................. 7
Visión .............................................................................................................................................. 7
Valores ........................................................................................................................................... 7
CAPITULO II................................................................................................................... 15
Alcance......................................................................................................................................... 18
....................................................................................................................................................... 19
Esquema de funcionamiento .................................................................................................... 19
Descripción Literal Detallada .......................................................................................... 23
Gestión de Cliente ...................................................................................................................... 23
Gestión de Agenda..................................................................................................................... 24
Gestión de Servicios .................................................................................................................. 24
Gestión de Difusión y Escucha al Cliente ............................................................................... 25
CAPITULO III ................................................................................................................. 26
Plataforma de Desarrollo........................................................................................................... 28
MVC (MODELO VISTA CONTROLADOR) ..................................................................... 37
MVVM (MODELO VISTA VIEW MODEL) ........................................................................ 38
CLIENTE-SERVIDOR...................................................................................................... 39
SOA (ARQUITECTURA ORIENTADA A SERVICIOS) ................................................... 39
PATRONES DE DISEÑO ................................................................................................ 40
PATRON DE CREACION SINGLETON .......................................................................... 41
PATRON DE ESTRUCTURA FACADE ........................................................................... 41
CAPITULO IV.................................................................................................................. 45
Estándares de Bases de Datos .................................................................................. 51
Estándares de Desarrollo............................................................................................... 60
Figura 1. Paleta de Colores. ............................................................................................ 87
........................................................................................................................................ 88
CAPITULO V ................................................................................................................... 94

2
Descripción del Capitulo................................................................................................................ 95

3
Introducción

El presente manual del sistema, tiene como propósito orientar al personal


‘de Spinetti Laser que manejará el Sistema de Información, proporcionando una
serie de métodos y términos que contribuyen al entendimiento del sistema
mediante la descripción de los procesos que deben realizarse para la ejecución de
cada una de las funciones del sistema, utilizando como material de apoyo las
imágenes de cada uno de los formularios y pantallas correspondientes a las
opciones disponibles.

El manual describe los lineamientos internos bajo los cuales fue creado el
sistema de Información Bambú, teniendo como objetivo ser un soporte formal en la
documentación del mismo, este contiene explicación de la plataforma
computacional utilizada para el desarrollo del sistema, estándares de
programación implementados, descripción de los módulos de los componentes
web, Desktop y aplicación móvil, así como también una pequeña descripción de la
organización en estudio. Bambú es un sistema de información creado para Spinetti
Laser el objetivo de facilitar la gestión de planificación de Agenda que lleva a cabo
la estética, el cual suministra información concerniente a las sesiones y, alianzas
estratégicas

De manera general, este manual lo instruye sobre el manejo del sistema


Bambú, describiendo su estructura para así poder moverse con facilidad dentro
del mismo.

4
CAPITULO I
LA ORGANIZACION

5
Descripción de la Organización

Grupo Spinetti es una entidad creada con el fin de prestar todo tipo de
servicios relacionados con la salud y belleza. Que van desde diagnósticos de
prevención, curación y rehabilitación hasta masajes faciales, corporales y
tratamientos de belleza, ayudando a mejorar la calidad de vida y el bienestar físico
y psíquico del cliente.

Para cumplir con dicha labor Grupo Spinetti tiene a la disposición de sus
clientes tres grandes empresas las cuales son Spinetti Laser, Spinetti Laser y
Unidad Quirúrgica del centro. En donde cada una de ellas se especializa en
diferentes actividades, las cuales se complementan unas con otras para la mayor
satisfacción del cliente. Igualmente las tres empresas actúan de forma autónoma e
independiente en cuanto al manejo de la información de sus clientes y
tratamientos llevados a cabo dentro de la organización, solo en casos especiales
los clientes son referidos de una empresa a otra proporcionándoles la información
requerida del mismo.

Así nace el grupo Spinetti, fue en octubre de 1986, después obtener


en la ilustre universidad de los andes el título de médico cirujano, cuando se
inicia este largo, ambicioso, costoso pero gratificante camino, que
emprendió un joven profesional, quien ya es conocido en la región como el
Doctor Eleazar Gómez Spinetti.

En el marco de su crecimiento profesional con diversos estudios realizados,


jornadas y experiencias, obtiene en 1990 en la capital de la republica la mención
de terapista en medicina alternativa, es allí cuando se regresa a su querida tierra
larense y se establece en un pequeño y modesto espacio en la parte externa del

Negocio de su madre la Sra. Adela de Gómez muy famosa para la época por la
venta de cerámica. Este lugar es reconocido desde entonces como el consultorio
del doctor Eleazar Gómez Spinetti.

6
Filosofía de la Gestion

Visión

Spinetti Laser, c.a. quiere ser una entidad con una cultura de Calidad
contribuyendo con la preservación de la vida, otorgando bienestar, relajación física
y mental que permitan a nuestros clientes enfrentar los males de la modernidad,
con técnicas especiales para su salud; y por tanto Posicionarnos como empresa
líder en el ramo, siendo reconocida a nivel local, nacional e internacional por la
calidad en el servicio.

Misión

Spinetti Laser, c.a. quiere ofrecer servicios estéticos integrales con


profesionales de máxima calidad que buscan que nuestros clientes experimenten
niveles únicos de armonía mente -Cuerpo, salud y belleza, a la vez de crear en un
hábito de cultura física en los mismos que les permite mantenerse saludables.

Valores

Estos valores declaran el compromiso de Spinetti Laser frente a todo su


público. Se reafirman valores y principios que inspiran el comportamiento de
quienes integran Spinetti Laser y quienes orientan todas sus relaciones:

Respeto

Se entiende el respeto como la “aceptación de otro como un legítimo otro”.


Se acepta que el otro siente, piensa y actúa de una manera diferente y que esa
manera propia es legítima, este respeto se propone como disposición básica en
todas las relaciones.

Honestidad

7
Se considera que las relaciones entre las personas deben darse entre un
marco de altas normas de honestidad e integridad de forma tal que cada uno
puedan tener confianza en la veracidad de lo que se escucha y la autenticidad de
las acciones que se observan.

Responsabilidad

Dedicados plenamente y con perseverancia a las causas y principios de


Spinetti Laser y reforzar el compromiso con las asociaciones y aliados con los
cuales se vincula. Con el fin de aumentar continuamente la eficacia de la
capacidad y procesos de los objetivos.

Objetivos

Objetivo General

Spinetti Laser, c.a Es una entidad creada con la finalidad de prestar


servicios simples que van desde un masaje facial, un masaje corporal a una gama
de servicios de un día o medio día de duración que incluyen faciales, tratamientos
corporales, tratamientos de belleza, baños de sauna vapor, capilares, tratamientos
de salud y bienestar, y en ciertos casos se le acompaña de ejercicios.

Objetivos Específicos

 Conocer las distintas necesidades de los clientes para orientar los servicios que
brinda Spinetti Laser y así garantizar una excelente atención.
 Ofrecer una atención programada y controlada de los servicios suministrados en
Spinetti Laser para el disfrute de los clientes.
 Brindar a los clientes una experiencia con niveles únicos de armonía, mente,
cuerpo salud y belleza a través de una gama de servicios de estética y salud.

8
Logotipo

Figura 1. Logo del Sistema.

Significado del Logotipo

Es la planta más popular en China, ya que todos los pueblos del sur de
China están rodeados de bosques de bambú, por lo cual para cualquier chino
estar cerca de un bambú, es estar cerca de casa. Otra relación cultural favorable
es que las hojas caídas de bambú se cruzan entre sí y generan la forma del
carácter chino "An" o “tranquilidad”. Bambú de la suerte está estrechamente
relacionado con el concepto de Feng Shui. Feng Shui es un antiguo arte chino y la
ciencia", basado en la visión taoísta de la comprensión de la naturaleza", y la
creencia de que la naturaleza es un ser vivo, lleno de energía. Esta antigua
práctica consiste en la unión de los elementos de fuego, tierra, madera, agua y
metal.

Estructura Organizacional

Estructura de Grupo Spinetti: La filosofía de gestión del Grupo Spinetti está


distribuida en tres (3) empresas donde cada una de ellas está registrada de
manera independiente, dichas empresas son Spinetti Laser C.A, Spinetti Spa Gym
C.A y Unidad Quirúrgica del Centro C.A; todas son lideradas por la misma
dirección general pero al momento de llevar a cabo su labor, actúan de forma

9
separada. A continuación se muestra la estructura organizacional del grupo
Spinetti:

Figura 2. Estructura Organizacional del grupo.

Estructura de la Organización (SPINETTI SPA GYM): Spinetti Laser cuenta con


una dirección general que es común a las tres empresas pertenecientes al grupo
Spinetti, esta se encarga de tomar las decisiones sobre los tratamientos que se
aplicaran y el equipo que se debe adquirir para dichos tratamientos, también elige
a los esteticistas

De la organización una vez estos han pasado por una entrevista previa y
hayan sido seleccionados, además de un área de administración que se encarga
de la actividad financiera de la organización, un asesor contable y un asesor
técnico. Para el disfrute y recibimiento de sus clientes cuenta un área de estética y
un gimnasio complementar los servicios ofrecidos.

10
Figura 3. Estructura Organizacional de Spinetti Spa Gym.

3. Estructura del Área (estética): El área de estética cuenta con los equipos
necesarios para los tratamientos, así como cuartos de sauna y vapor. Dicha área
consta de una recepción encargada de recibir a los clientes y programarles una
cita con el esteticista dependiendo de la Disponibilidad del mismo, o en casos
particulares que el cliente solicite. Cabe resaltar que cada uno de los esteticistas
está encargado de adquirir sus propios implementos e insumos para el desarrollo
del servicio. También cuenta con un área de mantenimiento que se encarga de la
limpieza y el orden de las instalaciones A continuación se muestra la estructura
organizacional de estética:

11
Figura 4. Estructura Organizacional del Área de Estética.

Área de Estudio

El propósito o razón de ser de Spinetti Laser se centra en la satisfacción y


bienestar de sus clientes la cual se logra por medio de la aplicación de
tratamientos de estética facial y corporal, todo esto llevado a cabo con las últimas
tecnologías y personal capacitado para prestar el mejor servicio y atención de los
clientes.

12
El área de estética cuenta con los equipos necesarios para los tratamientos,
así como cuartos de sauna y vapor. Dicha área consta de una recepción
encargada de recibir a los clientes y programarles una cita con el esteticista
dependiendo de la disponibilidad del mismo, o en casos particulares que el cliente
solicite. Cabe

Resaltar que cada uno de los esteticistas está encargado de adquirir sus
propios implementos e insumos para el desarrollo del servicio. También cuenta
con un área de mantenimiento que se encarga de la limpieza y el orden de las
instalaciones.

Entre los servicios ofrecidos se encuentran:

Tratamientos Faciales y Corporales:

 IPL.
 Radiofrecuencia Fraccionada.
 Eliminación de Tatuajes.
 Masoterapia.
 Cavitación.
 Presoterapia.
 Depilación Definitiva.
 Bronceado.
 Medicina China: Ventosas, Aromaterapia, Auriculoterapia.
 Limpieza de Cutis
 Servicios de Sauna y Vapor.

13
Cadena de Valor

Figura 5. Cadena de Valor.

14
CAPITULO II
EL SISTEMA

15
Descripción del Capitulo

En este capítulo se describe, el sistema de información Bambú, el


planteamiento de la solución, el desglose de los objetivos de la misma, se
especifica el alcance del sistema de acuerdo a las necesidades de Bambú, se
muestra el esquema de funcionamiento, la cadena de valor y el ciclo funcional de
software elaborado.

Planteamiento de la Solución
Se propone una solución informática basada en un sistema de información
denominado Bambú, con tres componentes fundamentales: Portal Web, Web-
Desktop y Aplicación Móvil, además se proporcionará un canal de escucha al
cliente, donde se permitirá ser flexible y adaptable a las gestiones de la
organización, como lo son la gestión de cliente, gestión de agendas y gestión de
servicios; con la finalidad de contar con la información distribuida adecuadamente.

La aplicación contará con funcionalidades amigables para el usuario en


relación a registros y reportes estadísticos con información valiosa para la toma de
decisiones en la organización y así prestar un mejor servicio en función a las TICs.

De igual manera se tomaran en cuenta los gustos y preferencia de los clientes


en materia de información para los servicios de prestación de la organización, y
los mismos tendrán relevancia para atención personalizada a través de
notificaciones a los clientes, correos electrónicos. Actividades como confirmación y
cancelación de citas, serán funcionalidades de los tres componentes mencionados
al principio como solución del sistema de información.

16
Objetivo General

Proporcionar información de calidad y de vital importancia para orientar la


toma de decisiones relacionadas específicamente con la atención al cliente,
agenda y servicios que presta Spinetti Laser c.a, con el fin de brindar una mejor
asistencia a su distinguida clientela, basado en una atención personalizada
tomando en cuenta sus gustos y preferencias para que así experimenten niveles
únicos de armonía mente-cuerpo, salud y belleza.

Objetivo Específico

 Brindar información de fácil acceso y actualizable acerca de los clientes, que


permita conocer los servicios solicitados, preferencias e historial, para facilitar la
determinación de las necesidades de los mismos y las tendencias dominantes en
cuanto a servicios.

 Garantizar un mejor servicio al cliente mediante el control de las citas

 Apoyar la gestión de servicios en concordancia con las citas confirmadas llevando


un seguimiento de los clientes para establecer indicadores de calidad que
permitan conocer los resultados de los tratamientos.

 Ofrecer un canal de difusión y escucha al cliente que permita conocer las


necesidades y opiniones de los mismos, con la intención de generar información
que apoye a la toma de decisiones gerenciales sobre los servicios prestados por
Spinetti Laser c.a, así como también poder difundir promociones y servicios
basado en los gustos y preferencias individuales.

17
Alcance
El sistema BAMBU está basado principalmente en registrar, procesar y
realizar un seguimiento al conjunto de actividades que se realizan dentro de cada
una de las gestiones, con la finalidad de proporcionar información útil para la toma
de decisiones; esto con el propósito de buscar soluciones y así facilitar el
funcionamiento de cada uno de los procesos que se ven involucrados en las
actividades que realiza día a día BAMBU. Los principales procesos que maneja el
sistema son: la Gestión de Clientes, La Gestión de Agendas y la Gestión de
Servicios.

Figura 6. Gestiones Principales.

El Área de Gestión de clientes, tiene como objetivo conocer las distintas


necesidades de los clientes para orientar los servicios que ofrece Spinetti Laser y
garantizar una excelente atención.

El Área de Gestión de Agenda forma parte de los procesos medulares de la


organización en cuestión, representando las actividades principales que se llevan
a cabo. Tiene como objetivo Garantizar una atención programada y controlada de
los servicios ofrecidos en Spinetti Laser para el disfrute de los clientes.

El Área de Gestión de Servicios forma parte de los procesos medulares de la


organización en cuestión, representando las actividades principales que se llevan
a cabo en ella. Tiene como objetivo ofrecer una gama de servicios que brinde
una experiencia única de relajación y armonía que lleven a nuestros clientes a

18
sentirse en un estado de bienestar tanto interno como externo todo esto mediante
tratamientos de estética y salud.

Esquema de funcionamiento

Gráfico

Figura 7. Esquema de Funcionamiento.

19
Descripción del Esquema de Funcionamiento

El sistema bambú contara con tres componentes principales, los cuales son:
portal web, aplicación movil y web desktop. Las cuales tendran diferentes
funcionalidades dependiendo el usuario que ingrese a dicho componente.

Los usuarios que maneja actualmente Bambú son: clientes, recepcionistas y


esteticistas, ademas de usuarios no registrados que pueden acceder a las
modalidades del portal web y la aplicación movil.

Los usuarios no registrados son aquellos que no han recibido ningun servicio
de la organización, pero que tienen interes en ello; estos pueden registrarse como
clientes potenciales y solicitar su consulta diagnostica ( primera cita) por el portal
web.

Los usuarios registrados o clientes son aquellos que estan registrado en el


sistema y que han recibido su consulta diagnostico, los cuales podrán ingresar
mediante su usuario y contraseña. El acceso a las funcionalidades sera de
acuerdo a la permisologia otorgada a los distintos roles en la configuaracion de
sistema.

En principio se tiene que el sistema esté enmarcado en los roles anteriormente


señalados, sin embargo, se podrán agregar nuevos usuarios según las
necesidades que surgan en la organización. Estos tendran roles configurables en
cuanto a las permisologias funcionales del sistema.

El portal web tienen como funcionalidad mostrar a los usuarios no registrados


toda la información referente a la organización asi como tambien todos los
servicios que ofrece Spinetti Laser , por lo cual podra solicitar su primera cita que
sera la consulta diagnostico, la cual arrojará como resultado los servicios por los
cuales puede optar. Ademas permitirá el registro del cliente con el que se le dará
acceso al sistema web desktop a traves de usuario y contraseña, siguiendo los
estandares de seguridad.

20
El sistema web desktop representa el componente principal este permitira
realizar todas las gestiones principales de la organización, como la gestion de
clientes, agenda y servicios, ademas de controlar la gestion de difusión y escucha
al cliente, gention de configuracion y parametrizacion, gestion de seguridad y otras
funcionalidades que den respuesta a las gestiones de apoyo que maneja la
organización. Desde este componente seran enviados a los clientes todas las
notificaciones hacia la aplicación movil acerca de su proxima cita y tratamientos.

La web desktop sera desarrollado en java 8 utilizando como IDE Eclipse Kleper
con el Framework ZK , Servidor Apache Tomcat 7.0.33, Maven, haciendo uso de
Json, Bootstrap, Jasper Report e Ireport 5.6.0 para la generacion de reportes, que
jugaran un papel importante dentro de la organización. El sistema sera visualizable
correctamente en los navegadores chrome y mozilla.

La aplicación movil centrará su atencion principalmente el la visualización de


notificaciones automáticas y personalizadas que radican los registros de las
proximas citas solicitadas por la web desktop, ademas de la cancelacion de las
mismas, permitiendo asi a los clienes confirmar su asistencias a las citas. Otro
aspecto es la seccion de contactanos con la cual los cliente podran colocarse en
contacto con la organización y presentarles sus dudas, quejas o sugerencias o
solicitar informacion.

La aplicación movil sera desarrollada en Android Nativo, en su Framework


Android Studio, haciendo uso de SQLite, SDK, Json y Rest Template, lo cual
permitira una visualizacion a traves de dispositivos que utilicen una version minima
de android 4.0.3.

Se utilizaran servicios web que permitiran la conexión del sistema web desktop,
la aplicación movil y el portal web con la base de datos. Seran desarrollados
haciendo uso de las siguientes herramientas Java 8, IDE Eclipse Kepler,
Hibernate, Apache Tomcat, PostgreSQL, Maven, Json Object, Gson.

La base de datos permitira el registro de todos los datos para dar respuestas
oportunas a todas las solicitudes de informacion por parte de los usuarios en el

21
sistema web desktop, portal web y la aplicación movil. Se utilizara como gestor de
base de datos PostgreSQL.

Cadena de Valor de la Solucion

Figura 8. Cadena de valor de la Solución.

22
Ciclo Funcional

Figura 9. Ciclo Funcional.

Descripción Literal Detallada


El ciclo funcional permite observar de manera detallada los principales
procesos desarrollados por la organización, mediante el análisis de las funciones
que se a cabo en cada una de las gestiones y sus relaciones lógicas con
información que se suministra desde el entorno o que se generan dentro de las
mismas funciones.

Gestión de Cliente
Da inicio cuando se realiza el registro del cliente potencial a través del
portal web junto con la solicitud del servicio que desea realizarse. Este registro
dará cita a una consulta diagnostica. Luego de esto, cuando el cliente se presente
a su consulta diagnostico se realizara el registro ya como cliente regular del spa;
se registraran los resultados de la consulta diagnostico en la cual se le dirá si está

23
apto o no para el servicio por el cual se postuló y cuales otros tratamientos puede
optar, así como también sus preferencias. Al obtener todos estos datos se procede
a registrar los servicios personalizados del cliente, que son los servicios o
tratamientos de los cuales puede elegir.

Al estar registrado como cliente, este obtendrá un usuario o contraseña con


el cual podrá ingresar a la web desktop o al portal móvil en los cuales podrá
registrar y/o modificar sus preferencias en el momento deseado. El procedimiento
sobre registrar el cliente se realiza una sola vez cuando el cliente asista por
primera vez al Spinetti Laser.

Gestión de Agenda
Luego de su primera cita (consulta diagnóstico), el cliente solicita una
segunda cita, donde se toman los datos correspondientes al tratamiento o servicio
a realizarse, ya con esto se realiza la asignación de recursos necesarios para
dicho tratamiento o servicio (cubículo, esteticista, etc.), esta información será
enviada vía correo electrónico al cliente.

El cliente tiene la oportunidad de reprogramar o cancelar su cita, bien sea


por la web desktop o por la aplicación móvil, un día antes de la fecha establecida
recibirá una notificación para que realice dichas actividad. Una vez que se lleven
a cabo alguna de estas opciones, automáticamente la agenda se actualizará de tal
forma que se pueda tener la información oportuna y actualizada, colocando este
horario bien sea disponible u ocupado confirmado.

Gestión de Servicios
Una vez realizada la cita, los datos recopilados sirven de entrada para la
gestión de servicio en donde se registra los servicios prestados y además una
descripción del avance o evolución que tenga. El esteticista registrará los servicios

Prestados detalladamente en la ficha de cliente, al igual que los avances que le ha


proporcionado el mismo.

24
El cliente también tiene la opción de ingresar a su cuenta en la aplicación
móvil y/o desktop, donde podrá leer sus avances y dar las opiniones y sugerencias
que tenga sobre el servicio que se le aplicó.

Las notificaciones tendrán la funcionalidad de informar al usuario sobre


eventualidades o inconvenientes que interfieran en su prestación de servicio,
nuevas promociones personalizadas a su perfil de preferencias y al momento que
el esteticista registre el avance de cada servicio prestado donde el usuario estará
informado de sus resultados y avances para que éste pueda realizar sugerencias,
opiniones y/o reclamos del mismo.

Gestión de Difusión y Escucha al Cliente

Esta se encuentra incluida en las gestiones antes nombradas, es acá donde


se manipulara cartelera informativa y buzón de sugerencias, en el cual los clientes
o clientes potenciales podrán dar sus sugerencias o solicitar información de los
servicios o tratamientos que ofrece el spa. Además será posible registrar noticias
que serán presentadas en la cartelera informativa, y que también podrán
desvincularse, aparte de registrar las opiniones de los usuarios también se
realizan encuestas con las cuales se obtendrá información de las necesidades de
los clientes.

25
CAPITULO III
PLATAFORMA COMPUTACIONAL

26
Descripción del Capitulo

En informática, una plataforma es un sistema que sirve como base para


hacer funcionar determinados módulos de hardware o software con los que es
compatible. El proceso de desarrollo se llevará a cabo en sistemas operativos
distribuidos tanto como software libre como software pago.

Es por esto, que estudiaremos de forma más técnica la funcionalidad del


Sistema de Información Bambú, en el cual se definirá su plataforma
computacional de desarrollo, estableciendo un sistema innovador en el ámbito
tecnológico y lograr un producto de óptima calidad, así como también permita una
fácil integración de los módulos que allí se desarrollan y establecer interfaces
adecuadas a los usuarios dependiendo de su esquema de funcionamiento.

Arquitectura del Software

Los patrones arquitectónicos, dan una descripción de los elementos y el


tipo de relación que tienen junto con un conjunto de restricciones sobre cómo
pueden ser usados.

Un patrón arquitectónico expresa un esquema de organización estructural


esencial para un sistema de software, que consta de subsistemas, sus
responsabilidades e interrelaciones. Un patrón arquitectónico es más un concepto
que captura elementos esenciales de una arquitectura de software. Muchas
arquitecturas diferentes pueden implementar el mismo patrón y por lo tanto
compartir las mismas características. La selección de un patrón arquitectónico es,
por lo tanto, una decisión fundamental de diseño en el desarrollo de un sistema de
software
27
Plataforma de Desarrollo

Bambú está diseñado e implementado como una aplicación compuesta, la


cual consta de una parte web que puede implementarse desde el navegador
Google Chrome, siendo independiente del sistema operativo, con facilidad para
actualizar y mantener la aplicación de una manera sencilla; por otro lado será una
aplicación de escritorio que dará soluciones a las necesidades particulares del
Hogar Canario Larense. Además contará con una base de datos centralizada y un
servidor para dar soporte a la misma. Los usuarios pueden acceder desde
cualquier lugar y en cualquier momento solo con el uso de un navegador web que
soporte la aplicación.

Herramienta de Desarrollo Utilizadas

28
Servicios web Intranet

 Apache Tomcat  Java 8.


 PostgreSQL.  IDE Eclipse Kepler.
 Java 8.  Framework ZK.
 IDE Eclipse Kepler.  Apache tomcat 7.0.33.
 Hibernate.  Apache Maven.
 Apache Maven.  Gson.
 Json Object.  Jasper Report.
 Gson.  IReport 5.6.0.
 GitHub.  Bootstrap
 GitHub.

Portal Web Aplicación Móvil

 ROR  Android Studio.


 IDE Eclipse Kepler.  Java 8.
 GitHub.  SQLite.
 Smartgit.  SDK.
 Bootstrap.  Gson.
 JQuery.  Rest Template.
 SUBLIME TEXTS  GitHub.

29
Descripción de Desarrollo Detalladas

Es una plataforma de desarrollo,


diseñada para ser extendida de forma
indefinida a través de plug-ins. Fue
concebida desde sus orígenes para
convertirse en una plataforma de
integración de herramientas de
desarrollo.

ZK es un framework de aplicaciones
web en AJAX, completamente
en Java de software de código
abierto que permite una completa
interfaz de usuario para aplicaciones
web sin usar JavaScript y con poca
programación.

PostgreSQL es un potente sistema de


base de datos objeto-relacional de
código abierto. Cuenta con más de 15
años de desarrollo activo y una
arquitectura probada que se ha ganado
una sólida reputación de fiabilidad e
integridad de datos. Se ejecuta en los
principales sistemas operativos que
existen en la actualidad como: Linux,
Windows y Unix.

30
Librería que permitirá convertir
cualquier objeto a formato Json.

Android Studio es el oficial entorno de


desarrollo integrado para la plataforma
Android. Fue anunciado el 16 de mayo
de 2013 en la conferencia Google I/O, y
reemplazó a Eclipse como el IDE oficial
para el desarrollo de aplicaciones para
Android. La primera versión estable fue
publicada en diciembre de 2014.

Trello es una aplicación web basada en


la de gestión de proyectos.

Maven es una herramienta de software


para la gestión y construcción de
proyectos Java creada por Jason van
Zyl, de Sonatype, en 2002. Es similar
en funcionalidad a Apache Ant (y en
menor medida a PEAR de PHP y CPAN
de Perl), pero tiene un modelo de
configuración de construcción más
simple, basado en un formato XML.

31
GitHub es una forja (plataforma de
desarrollo colaborativo) para alojar
proyectos utilizando el sistema de
control de versiones Git. Utiliza el
framework Ruby on Rails por GitHub,
Inc. (anteriormente conocida como
Logical Awesome).

Es un framework originalmente creado


por Twitter, que permite crear interfaces
web con CSS y JavaScript, cuya
particularidad es la de adaptar la
interfaz del sitio web al tamaño del
dispositivo en que se visualice.

Es una normativa de diseño enfocado


en la visualización del sistema operativo
Android, además en la web y en
cualquier plataforma. Fue desarrollado
por Google. Ampliando la interfaz de
tarjetas vista por primera vez en Google
Now.

Es una herramienta de Mapeo objeto-


relacional (ORM) para la plataforma
Java que facilita el mapeo de atributos
entre una base de datos relacional
tradicional y el modelo de objetos de
una aplicación, mediante archivos
declarativos (XML) o anotaciones en los

32
beans de las entidades que permiten
establecer estas relaciones.

Es un servidor web multiplataforma que


funciona como contenedor de servlets.
Es una herramienta flexible en tiempo
de ejecución y es considerado uno de
los servidores más populares gracias a
su fácil instalación y uso.

Proporciona un marco independiente de


la plataforma y de manera
independiente del protocolo para
construir aplicaciones de correo y
mensajería. El API JavaMail está
disponible como un paquete opcional
para su uso con la plataforma Java SE
y también se incluye en la plataforma
Java EE.

Es una biblioteca de código abierto para


el lenguaje de programación Java que
permite la serialización y deserialización
entre objetos Java y su representación
en notación JSON.

Spring MVC 4.0 RestTemplate. Es la


clase central de Spring para acceso
HTTP del lado del cliente.

33
Es una biblioteca de JavaScript, que
permite simplificar la manera de
interactuar con los documentos HTML,
manipular el árbol DOM, manejar
eventos, desarrollar animaciones y
agregar interacción con la técnica AJAX
a páginas web. Ofrece una serie de
funcionalidades basadas en JavaScript
que de otra manera requieran de
mucho más código.

Amplía nuestra plataforma de informes


Jaspsofter Web imbebible con una experiencia de
cuadros de mando mejorada, que permite a
los usuarios acceder fácilmente a los datos
que deseen.

Es un sistema de gestión de Base de


Datos relacional que permite almacenar
información en dispositivos empotrados
de una forma sencilla, eficaz, potente,
rápida y en equipos con pocas
capacidades de hardware, como puede
ser una PDA o un teléfono celular.

Software Development Kit. Mediante


este kit podemos desarrollar
aplicaciones y ejecutar un emulador de
la versión de Android. En Android todas
las aplicaciones se ejecutan en Java.
Tabla 1. Herramientas de Desarrollo Detalladas.

34
Metodología de Desarrollo

Para el desarrollo del sistema BAMBÙ, se utilizó una metodología híbrida


entre el modelo incremental, la Programación Extrema (XP) y el modelo de
Proceso Unificado Racional (RUP) por los siguientes motivos:

Para los componentes web y móvil del sistema BAMBÙ, hará uso del
modelo XP, puesto que dicha metodología, por su objetivo de potenciar las
relaciones interpersonales como clave para el éxito en el desarrollo de software,
resulta de gran utilidad para promover el trabajo en equipo, preocupándose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. A
pesar de ser una metodología que evita la documentación exagerada, es muy útil
para la organización del trabajo. De tal forma, la utilización de XP nos permite
aprovechar las siguientes características:

 Planeación: En éste punto se comienza a interactuar con el cliente y con el


equipo de desarrollo para identificar los requerimientos del sistema. Así mismo, se
identifica el número y tamaño de las etapas del proyecto. Igualmente, se logra
abstraer la información suficiente de cada punto de control para realizar la
implementación de las tareas, evitando ocasionar retrasos debido a la falta de
claridad en los requerimientos.
 Iteraciones: La creación del sistema se divide en etapas para facilitar su
realización, lo que permite llevar un mejor manejo y control de la información.
 Entregas Pequeñas y Frecuentes: Tanto en cada punto de control como al final
de cada etapa, se realiza una entrega de los avances del producto.
 Reuniones: Estas son continuas para facilitar la comunicación entre todos los
miembros del equipo.

La metodología RUP será implementada en la fase de documentación, puesto


que al trabajar sobre la misma se pretende un enfoque estructurado para realizar
tareas y responsabilidades en el proceso, así como tener un ordenamiento en la
documentación a ser utilizada en cada una de las etapas que involucra el

35
proyecto, estableciendo una terminología estándar, que mejora la comunicación
tanto externa como interna del equipo de desarrollo.

Por último, para desarrollar las diversas gestiones que posee la web desktop
(CLIENTES, AGENDA, SERVICIOS, TABLAS BASICAS, CONFIGURACION Y
PARAMETRIZACION) y para todo el proceso que conlleva la construcción de la
base de datos, es necesario hacer uso del modelo de componentes, ya que los
mismos poseen muchas características comunes; a su vez, cada uno de dichos
componentes serán desarrollados a través del modelo incremental, puesto que se
va a ir presentando un incremento de tareas realizadas en cada punto de control.

Figura 10. Metodología RUP Figura 11. Metodología XP

Arquitectura y Patrones de Software

Los patrones de diseño o modelos de abstracción utilizados para definir y


estructurar los componentes necesarios en el de desarrollo del Sistema de
Información Bambú son los siguientes:

Los patrones de arquitectura de software que se usarán son:

 MVC (Modelo Vista Controlador)


 MVVM (Modelo Vista View Model)

36
 Cliente-Servidor
 SOA (Arquitectura Orientada a Servicios)

MVC (MODELO VISTA CONTROLADOR)

Este patrón de arquitectura de software se basa en las ideas de reutilización de


código y la separación de conceptos, características que buscan facilitar la tarea
de desarrollo de la aplicación y su posterior mantenimiento.

Dividirá la aplicación en tres capas:

 Modelo (model): contiene la información central y los datos. Proveerá


mecanismos para acceder y actualizar estos datos. Su implementación es
independiente al resto de las capas.

 Vista (view): contiene el código de la aplicación que va a producir la visualización


de las interfaces de usuario. Interactúa directamente con el controlador.

 Controlador (controller): sirve de enlace entre las vistas y los modelos,


respondiendo a los mecanismos que puedan requerirse para implementar las
necesidades de la aplicación.

Figura 12 Modelo – Vista – Controlador.

37
MVVM (MODELO VISTA VIEW MODEL)

Es un patrón de arquitectura de software que facilita la separación en el


desarrollo de la interfaz gráfica de usuario del desarrollo de la lógica del negocio o
la lógica del back-end. El view model es un convertidor de valores, lo que quiere
decir que el view model es responsable de mostrar los objetos de datos del
modelo, de forma tal que esos objetos sean fácilmente manejados y presentados.
Al igual que el MVC, este patrón de arquitectura de software se basa en la
reutilización de código y la separación de conceptos, las cuales facilitan la tarea de
desarrollo de la aplicación y su posterior mantenimiento.

Dividirá la aplicación en 3 capas:

 Modelo (Model): contiene la información central y los datos. Proveerá


mecanismos para acceder y actualizar estos datos. Su implementación es
independiente al resto de las capas.

 Vista (view): contiene el código de la aplicación que va a producir la visualización


de las interfaces de usuario.

 View Model: sirve de enlace entre las vistas y los modelos, a través de un binder
(Enlazador), el cual trabaja con comandos y notificaciones, permitiendo tener
sincronizados la vista y el view model.

Figura 13. Capas Modelo – Vista – Controlador.

38
CLIENTE-SERVIDOR
Es un modelo de aplicación distribuida en el que las tareas se reparten entre
los proveedores de recursos o servicios, llamados servidores, y los demandantes,
llamados clientes. Un cliente realiza peticiones a otro programa, el servidor es
quien le da respuesta.
La separación entre cliente y servidor es una separación de tipo lógico, donde
el servidor no se ejecuta necesariamente sobre una sola máquina ni es
necesariamente un sólo programa.

Figura 14. Capas de cliente y Servidor.

SOA (ARQUITECTURA ORIENTADA A SERVICIOS)

Es una arquitectura que permite la creación de sistemas de información


altamente escalables que reflejan el negocio de la organización, a su vez brinda
una forma bien definida de exposición e invocación de servicios (comúnmente
pero no exclusivamente servicios web), lo cual facilita la interacción entre
diferentes sistemas propios o de terceros.

Para utilizar esta arquitectura es necesario familiarizarse con la siguiente


terminología:

39
 Servicio: Una función sin estado, auto-contenida, que acepta una(s) llamada(s) y
devuelve una(s) respuesta(s) mediante una interfaz bien definida. Los servicios
pueden también ejecutar unidades discretas de trabajo como serían editar y
procesar una transacción.

 Proveedor: La función que brinda un servicio en respuesta a una llamada o


petición desde un consumidor.

 Consumidor: La función que consume el resultado del servicio provisto por un


proveedor

Figura 15. Plataforma SOA.

Patrones de Diseño

Los patrones de diseño proveen un esquema para refinar los subsistemas o


componentes de un sistema de software, o las relaciones entre ellos. Son
menores en escala que los patrones arquitectónicos, y tienden a ser
independientes de los lenguajes y paradigmas de programación. Su aplicación no
tiene efectos en la estructura fundamental del sistema, pero sí sobre la de un
subsistema (Buschman et al., 1996), debido a que especifica a un mayor nivel de

40
detalle, sin llegar a la implementación, el comportamiento de los componentes del
subsistema.
Los patrones de diseño son soluciones bien pensadas a problemas conocidos de
programación y tienen como principio “No reinventar la rueda”.

Los patrones de diseño que se usarán son:

Patrón de Creación Singleton


Garantiza que una clase sólo tenga una instancia, y proporciona un punto de
acceso global a ella.
Este patrón puede ser utilizado cuando:
 Se requiere exactamente una instancia de una clase.

 Es necesario acceso controlado a un solo objeto.

Figura 16. Estructura del patrón Singleton.

Patrón de Estructura Facade


Proporciona una interfaz unificada para un conjunto de interfaces de un
subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más
fácil de usar.
Este patrón puede ser utilizado cuando:
 Se necesita una interfaz simple para proporcionar acceso a un sistema complejo.
 Hay muchas dependencias entre las implementaciones de sistemas y los clientes.

41
Figura 17. Estructura del patrón Facade.

Descripción de los Componentes de Software y Plugins

El desarrollo del sistema se realizó bajo el framework ZK, el cual permitió


Implementar, depurar, ejecutar y desplegar aplicaciones usando MVC (Modelo
Vista Controlador) y MVVM (Modelo Vista Modelo). El lenguaje de desarrollo del
lado del servidor se utilizó JAVA.
Como servidor de aplicaciones se hizo uso de Apache Tomcat, mientras que para
los servicios se usó Apache Tomcat.
Para la gestión de librerías se usó Maven en conjunto con otros componentes
Pequeños que complementan a los demás.
Para la aplicación móvil se usó el software de google Android Studio en conjunto.
Para la persistencia de datos trabajamos puntualmente con PostgreSQL
Gestionando la capa de modelo a través de las especificaciones comprendidas de
JPA por medio de Spring-Data-JPA y consultas con la herramienta de mapeo
(ORM) Hibérnate en la plataforma Java, además se usó ZK Framework para la
elaboración de las interfaces que se reflejan en los archivos de extensión .zul de la

42
aplicación. Para la generación de los reportes se usó JasperReports, en conjunto
con la librería iReport.

Servicios web

 El desarrollo del sistema se realizó bajo el framework ZK, que nos permitió
implementar, depurar, ejecutar y desplegar aplicaciones web recorriendo las
diferentes capas (Modelo, Vista y Servicios).
 El lenguaje de desarrollo del lado del servidor se utilizó JAVA.
 Como servidor de aplicaciones se hizo uso de Apache Tomcat 8.0 y Apache
Mave.

 Para la persistencia de datos trabajamos puntualmente con PostgreSQL


gestionando la capa de modelo a través de las especificaciones comprendidas de
JPA por medio de Spring-Data-JPA y consultas con la herramienta de mapeo
(ORM) Hibérnate en la plataforma Java, además se usó ZK Framework V8 para la
elaboración de interfaces que se reflejan en los archivos de extensión .zul de la
aplicación.
 Para la generación de los reportes se usó Jaspsofter.
 La plataforma de desarrollo es eclipse.
 Plataforma de desarrollo colaborativo GitHub.

Intranet

 El desarrollo del sistema se realizó bajo el framework ZK, que nos permitió
implementar, depurar, ejecutar y desplegar aplicaciones web recorriendo las
diferentes capas (Modelo, Vista y Servicios).
 El lenguaje de desarrollo del lado del servidor se utilizó JAVA.
 Como servidor de aplicaciones se hizo uso de Apache Tomcat 8.0

43
 Para la persistencia de datos trabajamos puntualmente con PostgreSQL
gestionando la capa de modelo a través de las especificaciones comprendidas de
JPA por medio de Spring-Data-JPA y consultas con la herramienta de mapeo
(ORM) Hibérnate en la plataforma Java, además se usó ZK Framework V8 para la
elaboración de interfaces que se reflejan en los archivos de extensión .zul de la
aplicación.
 Para la generación de los reportes se usó Jaspsofter.
 Para crear interfaces web con CSS y JavaScript. Bootstrap.
 Plataforma de desarrollo colaborativo GitHub.

Portal Web
 La plataforma de desarrollo es ROR.
 Plataforma de desarrollo colaborativo GitHub.
 Para crear interfaces web con CSS y JavaScript. Bootstrap.
 Plataforma de desarrollo colaborativo GitHub.
 JQuery manejar eventos, desarrollar animaciones y agregar interacción con la
técnica AJAX a páginas web.

Aplicación Móvil
 El lenguaje de desarrollo del lado del servidor se utilizó JAVA.
 Plataforma de desarrollo colaborativo GitHub.
 Android Studio es el oficial entorno de desarrollo integrado para la plataforma
Android.
 SQlite sistema de gestión de Base de Datos relacional que permite almacenar
información en dispositivos empotrados de una forma sencilla, eficaz, potente,
rápida y en equipos.
 SDK mediante este kit podemos desarrollar aplicaciones y ejecutar un emulador
de la versión de Android.
 Google-gson biblioteca de código abierto para el lenguaje de programación Java
que permite la serialización y deserialización.

44
CAPITULO IV
ESTANDARES

45
Descripción del Capitulo

En este capítulo se mencionarán los detalles usados para la elaboración del


sistema Bambú se explica la forma de cómo se trabajó en el proyecto, ofreciendo
una descripción de los estándares de presentación de menú, pantallas y
mensajes. En este capítulo se detallan los estándares de documentación de
código fuente, así como los estándares llevado en la programación (tal es el caso
de la declaración de variables, las clase, los comentarios, entre otros) y todos
aquellos estándares relacionados con el manejo de la base de datos. De igual
manera se explica lo concerniente a la presentación de las interfaces del sistema.

Estándares de Documentación

Con los estándares de documentación se pretende presentar


manuales ordenados y facilitar la lectura y el análisis de cada documento.
Dichos estándares son esenciales para lograr un diseño correcto y un
mantenimiento eficiente de los sistemas de información. Además de ser
precisa y completa, la documentación será instructiva, de modo que pueda
entenderse adecuadamente, cómo funciona el sistema, con solo leer la
documentación.

A continuación, se presenta los estándares a utilizar para la


documentación del sistema Bambú:

46
DC001 DOCUMENTACIÓN

TIPO Diseño de las páginas.

DESCRIPCIÓN Definición de diseño de las páginas.

CARACTERÍSTICAS PATRÓN EJEMPLO


El tamaño y tipo de la
página será:
Características de Carta: 21,59 cm x 27,94
configuración de cm.
páginas.
Los márgenes de las
páginas se medirán en
centímetros.
● Superior 1 cm.
● Inferior
La 1 cm de la
orientación
● Derechoserá
página 1 cm.
vertical.
● El Interlineado:
Izquierdo 1 cm. 1.15
Sangría: Tamaño 1.25

cm. La tecla “Tab”


tiene esta medida
por defecto.

DC002 DOCUMENTACIÓN

TIPO Portada

DESCRIPCIÓN Definición de la portada de los manuales

CARACTERÍSTICAS PATRÓN

47
La portada de cada manual tendrá centrado el nombre
DiseDiseño de las portadas del mismo, además de la especificación del tipo de
de los manuales. documento que se presenta. En la parte superior
izquierda se ubicará el logo del sistema desarrollador
“Bambú”. Finalmente, en la parte inferior del documento y
de manera centrada se encontrara el nombre del Equipo.
“TeamPoison”.

DC003 DOCUMENTACIÓN

TIPO Cuerpo del documento

DESCRIPCIÓN Definición de la presentación de los manuales

CARACTERÍSTICA PATRÓN EJEMPLO


S Habrá un índice por cada
manual y cada ítem del
mismo debe contener su
Índice propio hipervínculo.
El título del índice debe
estar centrado.
La lista de contenido
tendrá el número de
página en el que se
ubica.
Los capítulos tendrán su
respectivo número de
identificación.

48
Cada capítulo debe
Capítulo comenzar en una nueva 1. MAYÚSCULAS
1.1. MAYÚSCULAS
página y el nombre debe
al Minúsculas
estar centrado junto 1.1.1.
1.1.1.1. Minúsculas
número de identificación
del mismo.
Al inicio de cada capítulo
debe explicarse
brevemente el contenido
del mismo.
Debajo del capítulo e
igualmente centrado se
encontrara el nombre del
mismo.

Se debe entre
El espacio mantener la
epígrafe
sangría
2 “enter”. al comenzar el
texto.

Numeración de los
El espacio entre párrafos
apartados y
1 “enter”.
subapartados: Se
utilizara los números
arábigos.

Estos tendrán fuente TITULO


Título determinado, con una
alineación a la izquierda.

49
Estarán de acuerdo
según el nivel.
● De 1er nivel: Fuente en
negrita y alineados a la
izquierda.
● De 2do nivel: Fuente en 1.1. SUBTITULO 1
Subtítulos negrita y alineados a la 1.2 SUBTITULO2
izquierda, con doble
tabulado.

Los párrafos serán color


Párrafo negro y además deben
estar justificados.
En aquellos casos que1.1 Contenido
Numeración sea necesaria la1.2 Contenido
numeración será
1.2.1 Contenido
empleado de la siguiente
1.2.1.1 Contenido
manera.
1.2.1.2 Contenido
La identificación de las 2.1 Contenido
gráficas e imágenes se
realizará como se
describe a continuación:

50
Representación La palabra FIGURA,

gráfica seguidamente de un
número de identificación
que irá de manera
consecutiva, finalmente el
nombre de la figura. Esta
información se encontrará
centrada en la parte
inferior de la figura. No
contendrá bordes.

Títulos principales de
columnas y/o filas deben
ir centrados y con inicial
en mayúsculas.
Los títulos secundarios
de cada fila y/o columna
deben ir en negrita y sólo
la primera letra en
mayúsculas alineados y
a la izquierda.
El contenido de las
tablas estará justificado
y alineado.

Estándares de Bases de Datos

BD001 BASE DE DATOS

DESCRIPCIÓN Definición de reglas generales de la Base de


Datos

51
CARACTERÍSTICAS PATRÓN EJEMPLO

En los nombres de las


tablas y columnas, se
usarán únicamente
caracteres alfabéticos, salvo
que por la naturaleza del
nombre, se necesiten
dígitos numéricos. Se
prohíbe el uso de caracteres
de puntuación y puntos.

Las letras acentuadas se


país→
reemplazarán con el
pais año
equivalente no acentuado y → anno.
Condiciones en lugar de la letra “ñ”, se
Generales de utilizará “nn”.
Nomenclatura
No se usarán tipos de datos
char, en su lugar usar
String, que en la base de
datos serán convertidos
como character varying(1)

52
Evitar tener demasiadas
columnas Nulas
(NULLABLES) en una tabla.
Esto es indicio de un
esquema poco o nada
normalizado. Falta de
normalización puede
conllevar problemas de
consistencia en los datos en
la medida que un mismo
campo se puede terminar
almacenando en varias
tablas. Excesiva
normalización puede tener
asociada una pérdida de
performance en ciertas
operaciones sobre la base
de datos. Es necesario
encontrar el equilibrio
correspondiente a los
requerimientos de cada
proyecto en este punto.
Como regla general la
tercera forma normal es un
buen punto intermedio

Evitar tener tablas


innecesarias en el sistema.
Un buen diseño es uno
simple.

BD002 BASE DE DATOS 53


DESCRIPCIÓN Definición del nombre de la Base de Datos

CARACTERÍSTICAS PATRÓN EJEMPLO


Nombre de la Base de Datos Nombre del Software BambuWebservice

BD003 BASE DE DATOS

DESCRIPCIÓN Definición de los nombres de las tablas de la base


de datos.
CARACTERÍSTICAS PATRÓN EJEMPLO

54
Los nombres de las
tablas deben ser
sustantivos, en singular
y totalmente en
minúsculas, en caso de
estar compuesto por
dos o más palabras, tb_esteticista;
Nombre de las separarlas con un tb_horario_esteticist
tablas subguión ("_"). Deben a;

estar precedidos del


término ‘tb_’. Intentar
mantener los nombres
de las tablas simples y
descriptivas. Usar
palabras completas,
evitar acrónimos y
abreviaturas (a no ser
que la abreviatura sea
mucho más conocida
que el nombre completo,
como URL o HTML).

BD004 BASE DE DATOS

DESCRIPCIÓN Definición de las características a utilizar en los


nombres de las columnas de las tablas

CARACTERÍSTICAS PATRÓN EJEMPLO

55
Los nombres de las
columnas deben estar en nombre
Nombre de las singular y en minúscula.
columnas de Si se necesita más de
las tabas una palabra, se separan id_horario_equip
con el carácter “_”
o

BD005 BASE DE DATOS

DESCRIPCIÓN Definición de las secuencias utilizadas en la base de


datos del sistema.

CARACTERÍSTICA PATRÓN EJEMPLO


S
Los nombres de las
CREATE SEQUENCE
secuencias deben iniciar
tb_esteticista_id_seq
con el nombre de la tabla
INCREMENT 1
a la que pertenecerán,
Nombre de MINVALUE 1
seguidos del término
las MAXVALUE
‘_id_seq’. Serán usadas
secuencia 9223372036854775
para autoincrementar
s 807
los valores de las
START 1
claves primarias de
CACHE 1;
cada tabla.

56
BD006 BASE DE DATOS

DESCRIPCIÓN Definición de las claves utilizadas en la base de


datos del sistema.
CARACTERÍSTICAS PATRÓN EJEMPLO

Los nombres de las


claves primarias deben ALTER TABLE tb_agenda

estar precedidos por el ADD COLUMN id_agenda

término ‘id_’, seguido con numeric(9); ALTER TABLE

el nombre de la tabla a la tb_agenda ALTER COLUMN

que pertenece. Su tipo id_agenda SET NOT NULL;

de dato debe ser numeric ALTER TABLE tb_agenda


Claves Primarias
(9), autoincrementable, ALTER COLUMN id_agenda

no puede guardar valores SET DEFAULT

NULL. Debe cumplir con nextval('tb_agenda_id_seq'::r

el estándar de nombre de eg class);

columnas.

57
BD007 BASE DE DATOS

Definición de la relación de los tipos de datos


DESCRIPCIÓN utilizados en la base de datos PostgreSQL y Java
CARACTERÍSTICAS PATRÓN EJEMPLO

Se utilizará la palabra
“fk” la cual representa ALTER TABLE
una Foreign Key, tb_horario_equipo ADD
seguida del símbolo “_” COLUMN fk_equipo_horario
y luego el nombre de la numeric(9);
tabla con la que está
Claves Secundarias relacionada. Siempre ALTER TABLE
todo en singular, tb_horario_equipo ADD
completamente en CONSTRAINT
minúscula. Su tipo de fk_tb_horario_equipo_r_tb_
dato debe ser numeric horario_equipo FOREIGN
(9). Debe cumplir con el KEY (fk_equipo_horario)
estándar de nombre de REFERENCES
columnas. tb_horario_equipo
(id_horario_equipo) MATCH
SIMPLE;

58
Los valores
alfanuméricos en - Java → String

PostgreSQL deben - PostgreSQL character


Valores definirse character varying(x)
Alfanuméricos varying(x), donde x es el x: Tamaño que se
tamaño debe tener el considere necesario.
mismo, y en java se
debe definir String
Las claves primarias y
foráneas en PostgreSQL
Claves Primarias y deben definirse numeric - Java → Integer
Foráneas (9) y en java se debe - PostgreSQL→ numeric(9)
definir Integer.

Los valores sin punto


Valores sin punto flotante en PostgreSQL - Java → Integer/Long
flotante deben definirse datos - PostgreSQL numeric(x)
(Exceptuando numeric(x), donde x es el
x: Tamaño que se
Claves Primarias y tamaño debe tener el
considere necesario
Foráneas) mismo, y en java se debe
definir Integer o Long

Los campos que hagan


referencia en - Java → Long
Campos de fechas PostgreSQL deben
- PostgreSQL numeric(16)
definirse numeric (16) y
en java se debe definir
Long.

59
Los valores con punto
flotante en PostgreSQL - Java → Double
Valores con punto deben definirse datos - PostgreSQL double
flotante double precisión y en precision
java se debe definir
Double
Los valores booleanos en
PostgreSQL deben - Java → Boolean
Valores Booleanos definirse datos boolean y - PostgreSQL Boolean
en java se debe definir
Boolean

Estándares de Desarrollo

Los estándares de desarrollo de software que se usarán están basados


en las convenciones de código para el lenguaje de programación java, el
cual fue creado por Sun Microsystems Inc.

DE001 DESARROLLO

TIPO Fichero fuente Java

60
Fichero fuente Java (.java)

Cada fichero fuente Java contiene una única clase o


interface pública. Cuando algunas clases o interfaces
privadas están asociadas a una clase pública, pueden
ponerse en el mismo fichero que la clase pública.

La clase o interfaz pública debe ser la primera clase o


DESCRIPCIÓN
interface del fichero.

Los ficheros fuentes Java tienen el siguiente orden:

- Comentarios de comienzo.

CARACTERÍSTICAS - Sentencias
PATRÓN package e import. EJEMPLO
- Declaraciones de clases e interfaces.
/** @AgendaDAO
Todo fichero fuente
*
debe comenzar con un
*Implementación de
comentario que incluya el
las
nombre de la clase, fecha
*operaciones de la capa
Comentarios de de la última modificación,
DAO de
Inicio descripción de la clase,
personas que han *la entidad
modificado el archivo, *
información de la versión, *Última modificación
fecha, y *dd/mm/YYYY
copyright
*
*Informacion de la version

* Copyright
*
* @autor TeamPoison
*/

61
La primera línea no
comentada de un fichero
fuente debe ser la
Sentencias de sentencia de paquete, que package javax.crypto;
Paquete indica el paquete al que
pertenece(n) la(s) clase(s)
incluida(s) en el fichero
fuente.
Tras la declaración del
paquete se incluirán las
sentencias de importación
Import java.io.*;
de los paquetes
necesarios. No se
permitirán imports sin import java.util.ArrayList;

Sentencias de usar. Esta importación de


importación paquetes obligatorios
seguirá el siguiente orden:
1. Paquetes del JDK de
java.

2. Paquetes de utilidades
import
no pertenecientes al JDK
org.apache.log4j.Logger;
de Java, de framework de
import
desarrollo o de proyectos
org.apache.lucene.analysis.
open source tales como
apache, spring framework, Anal yzer;

etc.

import
3. Paquete de la aplicación.
proyecto.modelos.Estetici
sta;

62
Las partes de una clase o
/** @EsteticistaDAO
interface debe contener el
*
siguiente orden:
*Implementación de
Declaraciones de las
1. Comentario de
clases e interfaces
documentación de la clase *operaciones de la capa

o interface. DAO de
*la entidad

2. Sentencia class o ...

interface */
3. Comentario de
implementación de la
clase o interface si fuera
necesario. Este
comentario debe contener /* ...

cualquier información */
aplicable a toda la clase o
interface que no era
apropiada para estar en
los comentarios de
documentación de la
clase o interface.

4. Variables de clase
(static), primero las
variables de clase public,
después las protected,
después las de nivel de
paquete (sin modificador de
acceso), y después las
private.

63
5. Variables de instancia,
primero las public, después
las protected, seguidas de
las de nivel de paquete (sin
modificador de acceso), y
después las private.

6. Constructores de la clase
o interface

7. Métodos, los cuales se


deben agrupar por
funcionalidad más que por
visión o accesibilidad. Por
ejemplo, un método de
clase privado puede estar
entre dos métodos
públicos de instancia. El
objetivo es hacer el
código más legible y
comprensible. Los
métodos de set y get de
objetos deben estar al final
de la clase.

64
DE002 DESARROLLO
TIPO Identación.

DESCRIPCIÓN Reglas de identación del código.

CARACTERÍSTICAS PATRÓN EJEMPLO


Evitar las líneas de más
de 80 caracteres, ya que
no son manejadas bien
por muchas terminales y
herramientas.
Longitud de la Nota: Ejemplos para uso
línea en la documentación
deben tener una longitud
inferior, generalmente no
más de 70 caracteres.

65
Cuando una expresión
no entre en una línea,
romperla de acuerdo con
estos principios:
- Romper después de una
coma.
- Romper antes de un
operador.
- Preferir roturas de alto un
nivel (más a la derecha Método(expresionLarga1,
que el "padre") que de expresionLarga2,
bajo nivel (más a la expresionLarga3,
izquierda que el "padre"). expresionLarga4,
Rompiendo líneas
- Alinear la nueva línea expresionLarga5);
con el comienzo de la
expresión al mismo nivel
de la línea anterior.
- Si las reglas anteriores
llevan a código confuso
o a código que se
aglutina en el margen
derecho, indentar justo 8
espacios en su lugar.

66
DE003 DESARROLLO
TIPO Comentarios de implementación

Los programas Java pueden tener dos tipos de


comentarios: comentarios de implementación y
comentarios de documentación.

Los comentarios de implementación son aquellos que


están delimitados por /*...*/ y //.

Los comentarios de documentación (conocidos como


"doc. comments") existen sólo en Java, y se limitan por
/**...*/. Los comentarios de documentación se pueden
DESCRIPCIÓN exportar a ficheros HTML con la herramienta javadoc.

Los comentarios de implementación son para comentar


nuestro código o para comentarios acerca de una
implementación particular. Los comentarios de
documentación son para describir la especificación del
código, libre de una perspectiva de implementación, y para
ser leídos por desarrolladores que pueden no tener el
código fuente a mano.

CARACTERÍSTICAS PATRÓN EJEMPLO

67
/*
Se usan para dar
* Aquí hay un comentario de
descripciones de
bloque.
ficheros, métodos,
*/
estructuras de datos y
algoritmos. Los
Los comentarios de bloque
comentarios de bloque
pueden comenzar con /*-, que
se podrán usar al
es reconocido por indent(1)
comienzo de cada
como el comienzo de un
fichero o antes de cada
comentario de bloque que no
Comentarios de método. También se
debe ser formateado.
bloque pueden usar en otro
/*-
lugares, tales como el
* Aquí tenemos un
interior de los métodos.
comentario de * bloque con
Los comentarios de
cierto
bloque en el interior de
* formato especial que
una función o método
quiero que * ignore indent
deben ser indentados al
(1).
mismo nivel que el
* Uno
código que describen.
* dos
Pueden aparecer
*/
comentarios cortos de
una única línea al nivel if (condición) {
del código que siguen. /* Código de la condición. */
Comentarios de una
Si un comentario no se ...
línea
puede escribir en una
}
línea, debe seguir el
formato de los
comentarios de bloque.

68
Pueden aparecer
comentarios muy if (a == 2) {
pequeños en la misma return TRUE; /* caso especial
Comentarios de
línea que describen, pero */
remolque
deben ser movidos lo } else {
suficientemente lejos para
return isPrime(a); /*caso
separarlos de las
general */
sentencias.
}
if (foo > 1) {

El delimitador de // Hacer
comentario algo.

// Puede convertir en ...


comentario una línea }
completa o una parte de else {
una línea. No debe ser
return false; // Explicar aquí
usado para hacer
Comentarios de fin de línea }
comentarios de varias
//if (bar > 1) {
líneas consecutivas; sin
embargo, puede usarse // // Hacer algo.
en líneas consecutivas // ...
para comentar //}
secciones de código. //else {
// return false;
//}

69
Los comentarios de
documentación /**

describen clases Java, * Esta es la descripción


interfaces, * breve del método
Comentarios de constructores, métodos * Ultimo modificación
documentación y atributos. Cada *dd/mm/YYYY
comentario de
* @author Nombre del Autor
documentación se
*/
encierra con los
public class Ejemplo { … }
delimitadores de
comentarios
/**...*/, con un
comentario por clase,
interface o miembro
(método o atributo).
Cada método deberá
tener un comentario con
la siguiente estructura:
Descripción breve, fecha,
etiquetas con autor.
Excepto los métodos set,
get.
Si el método es complejo
y extenso, se harán
comentarios explicativos
DE004 dentro del mismo.
DESARROLLO
TIPO Declaraciones

DESCRIPCIÓN Reglas de declaración de variables.

CARACTERÍSTICAS PATRÓN EJEMPLO

70
int nivel; // nivel de
Se recomienda una identación int tam; //
declaración por línea, tamaño de la tabla
Cantidad por línea
ya que facilita los
comentarios. EVITAR:
int level, size;

Intentar inicializar las Agenda agenda = new


variables locales donde Agenda();
se declaran. La única
razón para no inicializar List<Agenda> agenda = new
una variable donde se Array List();
Inicialización declara es si el valor
inicial depende de EVITAR:
algunos cálculos que
Agenda agenda = null
deben ocurrir. Evitar la
inicialización de objetos
en null.

71
void myMethod() {

Poner las declaraciones int int1 = 0; //

solo al principio de los comienzo del bloque del

bloques (un bloque es método

cualquier código if (condition) {

encerrado por llaves "{" y int int2 = 0; //


"}".) No esperar al primer comienzo del bloque del "if"
uso para declararlas; ...
puede confundir a }
Colocación
programadores no }
preavisados y limitar la
portabilidad del código
La excepción de la regla son
dentro de su ámbito de los índices de bucles for, que
visibilidad.
en Java se pueden declarar
en la sentencia for:

for (int i = 0; i <


maximoVueltas; i++)
{ ... }

72
Al codificar clases e
interfaces de Java, se
siguen las siguientes
reglas de formato:

● Ningún espacio en
blanco entre el nombre
class Ejemplo extends Object {
de un método y el int ivar1;
paréntesis "(" que abre int ivar2;
su lista de parámetros.

Ejemplo(int i, int j) {
● La llave de apertura "{" var1 = i;
aparece al final de la ivar2 = j;
Declaraciones de misma línea de la
}
clases e interfaces sentencia declaración.
La llave de cierre "}"
int metodoVacio() {}
empieza una nueva
...
línea indentada para
}
ajustarse a su sentencia
de apertura
correspondiente,
excepto cuando no
existen sentencias entre
ambas, que debe
aparecer
inmediatamente
después de la de
apertura "{".
Los métodos se separan
con una línea en blanco.

73
- Singular: Se usará para
el llamado de objetos y
atributos, se marca en
private() y el nombre private User user;

comienza en minúscula
solo la primera palabra
siguiendo el mecanismo
camelCase.

- Plural: Se usará para el


Declaraciones de
llamado de listas, se
entidades
marca con private y el
nombre comienza en
private List<User> users;
minúscula y al final se
agrega una “s” siguiendo
el mecanismo
camelCase.

Para los métodos de


clases, la primera letra
debe ser minúscula
siguiendo el
Declaración de
mecanismo camelCase Public User buscarUsuario
método
los métodos no pueden (){...}
exceder las 200 líneas
de código.

74
DE005 DESARROLLO
TIPO Sentencias

DESCRIPCIÓN Reglas de declaración y uso de sentencias.

CARACTERÍSTICAS PATRÓN EJEMPLO

argv++; //
Cada línea debe contener
Correcto
Sentencias simples como mucho una sentencia.
argc--; //
Correcto
argv++; argc--; //
EVITAR

75
Las sentencias compuestas
son sentencias que
contienen listas de
sentencias encerradas
entre llaves "{sentencias}".
Las sentencias encerradas
se deben indentar un nivel
más que la sentencia
compuesta.
La llave de apertura se
debe poner al final de la
línea que comienza la
sentencia compuesta; la
Sentencias llave de cierre debe
compuestas empezar una nueva línea y
ser indentada al mismo
nivel que el principio de la
sentencia compuesta.
Las llaves se usan en todas
las sentencias, incluso
las simples, cuando
forman parte de una
estructura de control, como
en las sentencias if- else o
for. Esto hace más sencillo
añadir sentencias sin
incluir bugs
● accidentalmente por
olvidar las llaves.

76
Una sentencia return con un
return;
valor no debe usar
paréntesis a menos que
return miDiscoDuro.size();
hagan el valor de retorno
Sentencias de
más obvio de alguna
retorno return (tamanyo ?
manera.
tamanyo :
tamanyoPorDefect
o);

if (condición) {
sentencias;
}

if (condición) {
sentencias;
} else {
sentencias;
Para el manejo de
Sentencias sentencias condicionales }

condicionales tomar en cuenta la


correcta indentación de las if (condición) {

mismas. Sentencia;
} else if (condición) {
Sentencia;
} else {
Sentencia;
}

77
Se debe evitar el uso de
for índice, debido a que for (Object
esta estructura consume myObjetc :
mayor memoria de la JVM this.getListObjet
(Máquina Virtual Java), en cs()) {}
Sentencias de
su lugar se deben usar for
bucles
iterativos //EVITAR
for (int i = 0; i<tamaño;
i++) {}

while (condición) {
Para nomenclaturas while y
sentencias;
do-while, tomar en cuenta
}
las convenciones de
indentación.
do {
sentenc
ias;
} while (condición);

78
switch (condición) {
case ABC:
Sentencias;
Cada vez que un caso se
/* este caso se propaga */
propaga (no incluye la
sentencia break), añadir un
case DEF:
comentario donde la
sentencia break se Sentencias;

encontraría normalmente. break;

Sentencias switch Cada sentencia switch debe case XYZ:

incluir un caso por defecto. Sentencias;


El break en el caso por break;
defecto es redundante, pero
prevé que se propague por default:
error si luego se añade otro Sentencias;
caso. break;
}

79
try {
Sentencias;
} catch (Exception Class
e) { Sentencias;
}
Una sentencia try-catch
puede ir seguida de un
finally, cuya ejecución se
try {
Sentencias try-catch ejecutará
independientemente de Sentencias;
} catch (Exception Class
que el bloque try se haya
completado con éxito o no. e) { Sentencias;
} finally {
Sentencias;
}

DE006 DESARROLLO

TIPO Espacios en Blanco

DESCRIPCIÓN Reglas de uso de espacios en blancos en el código.

CARACTERÍSTICAS PATRÓN EJEMPLO

80
Se deben usar siempre dos líneas
en blanco en las siguientes
circunstancias:

● Entre las secciones de un fichero


Las líneas en blanco fuente.
mejoran la facilidad de● Entre las definiciones de
lectura separando clases e interfaces.
Líneas en blanco
secciones de código
que Se debe usar siempre una línea en
están blanco en las siguientes
lógicamente circunstancias:
relacionadas.
● Entre método

● Entre las variables locales de un


método y su primera sentencia.
● Antes de un comentario de bloque o
de un comentario de una línea.
Entre las distintas secciones
lógicas de un método para facilitar
la lectura.

81
● Una palabra clave del lenguaje
seguida por un paréntesis debe
separarse por un espacio. Ejemplo:
while (true) {...}
● Debe aparecer un espacio en
blanco después de cada coma en
las listas de argumentos.
Todos los operadores binarios se
deben separar de sus operando con
espacios en blanco.
Los espacios en blanco no deben
separar los operadores unarios,
incremento ("++") y decremento ("--")
de sus operando. Ejemplo:
No se debe usar un a += c + d;
espacio en blanco
a = (a + b) / (c * d);
entre el nombre de un
while (d++ == s++) { n++;}
Espacios en método y su
Las expresiones en una sentencia for
blanco paréntesis de
se deben separar con espacios en
apertura. Esto ayuda
blanco. Ejemplo:
a distinguir palabras
for (expr1; expr2; expr3)
claves de llamadas a
Los "Cast" deben ir seguidos de un
métodos.
espacio en blanco. Ejemplo:
miMetodo((byte) unNumero, (Object)
x);
miMetodo((int) (cp + 5), ((int)
(i + 3)) + 1);

82
DE007 DESARROLLO
TIPO Convenciones de nombre

DESCRIPCIÓN Reglas de los nombres de objetos y paquetes del sistema.

CARACTERÍSTICAS PATRÓN EJEMPLO

El prefijo del nombre de un com.sun.eng


paquete se escribe siempre com.apple.quicktime.v2
con letras ASCII en edu.cmu.cs.bovik.cheese
Paquete
minúsculas.

Los nombres de las clases


deben ser sustantivos,
cuando son compuestos
tendrán la primera letra de class Cliente;
cada palabra que lo forma
Clases en mayúsculas. Intentar class ImagenAnimada;
mantener los nombres de
las clases simples y
descriptivas. Usar palabras
completas, evitar
acrónimos y abreviaturas (a
no ser que la abreviatura
sea mucho más conocida
que el nombre completo,
como URL or HTML).

83
Los nombres de las
interfaces siguen la misma
regla que las clases.
Interfaces interface
ObjetoPersistente;

Excepto las constantes,


interface Almacen;
todas las instancias y
variables de clase o método
empezarán con minúscula.
Las palabras internas que lo
forman (si son compuestas)
empiezan con su primera
letra en mayúsculas. Los
nombres de variables no
deben empezar con los
caracteres subguión "_" o int i;
signo del dólar "$", aunque
ambos están permitidos char c;
Variables por el lenguaje.
Los nombres de las float miAnchura;
variables deben ser cortos
pero con significado.
Los nombres de variables de
un solo carácter se deben
evitar, excepto para variables
índices temporales. Nombres
comunes para variables
temporales son i, j, k, m, y n
para enteros; c, d, y e para
caracteres.

84
static final int
ANCHURA_MINIMA
Los nombres de las = 4;
variables declaradas como
constantes deben ir static final int
Constantes
totalmente en mayúsculas
ANCHURA_MAXIMA = 999;
separando las palabras con
un subguión ("_").
Los nombres de las entidades static final int
estarán en singular, los COGER_LA_CPU = 1;
objetos se definirán con el
nombre exacto se llamará en
la base de datos, a menos
que la tabla tenga algún
nombre reservado, el nombre
Entidades del objeto debe comenzar con User.java;

la primera letra en mayúscula


siguiendo el mecanismo
camelCase y las entidades en
la Base de Datos se manejan
en minúscula con “_” como
separador.

85
En cuanto al nombre la PPublic enum Evaluation
DE008 DESARROLLO
misma convención de los Type {
TIPO Hábitos de Programación
objetos, se declararán al GENERAL("General"),
DESCRIPCIÓN Convenciones con respecto a hábitos de programación.
menos dos atributos que son

CARACTERÍSTICAS valor, nombre y se accederá REPROGRAMMED("Reprogr


PATRÓN EJEMPLO
o se comparara por el get de ama dos");
Evitar usar un objeto para
valor (en caso de que sea public final String value;
acceder a una variable o
necesario, sino se creará un private Evaluation
método de clase (static).
atributo de tipo valor, Type(String
Usar el nombre de la clase this.metodoDeClase(); //OK
value) {
manejar los enum como UnaClase.metodoDeClase();
en su lugar.
clases estáticas). This. Value = value;
Todos los métodos de la //OK
clase se deben llamar }

dentro de la misma unObjeto.metodoDeClase()


Referencias a utilizando la notación ;public String get Value()
variables y métodos this.miMetodo(). { return value;
//EVITAR
de clase No se permite: Dejar }

variables y métodos en la
clase que no se están }

usando, ya que esto hace


que el código pierda public List<Usuario>
Para el uso de listas en
estándares de calidad. getUsuarios() {
las clases se deben
if (Usuario == null) {
realizar métodos
usuarios= new Array
Estándares de Presentación
Método defensivos defensivos en el get, es
List<>();
decir, las inicializaciones
}
Descripción de la de interfaz gráficasededeben
las listas usuario, en donde utilizando un
return usuarios
conjunto de imágenes y objetos
hacer en
Hacer gráficos,
uso
su get.
de selistas
representa
en la información y acciones
disponibles en la interfaz;lugar
con de
el fin
arreglos, debido }un entorno visual sencillo;
de pre-visualizar
enfocado en la experiencia
a de
queusuario
las listas
y laconsumen
interacción.
menos memoria de la
JVM. En caso de usar un
Enumerados
arreglo, este debe ser getMiListObjetc ().add 86
Uso de Listas justificado. Emplear los All(getMyListOrigin());
métodos propios de la
1. PALETA DE COLORES

Figura 18. Paleta de Colores.

La gama de colores principal es la siguiente: Verde #4CAF50, verde oscuro


#73A133, verde mostaza #968700, verde mostaza claro #A4C123, verde agua
#8AC249 Además de dos tonos más claros y dos más oscuros de los colores
dados.

Uno gris oscuro #BEBEBE, y unos gris claro #FFFF y otro gris claro #FFFF y otros
gris agua #FAFAFA , además de rojo #ED5565.

87
2. BOTONES

Figura 19.Botones.

Botón GUARDAR, lo usara cuando el usuario esté de acuerdo con la


transacción.

Tipos de Pantallas

En el siguiente espacio podremos detallar los distintos tipos de pantallas


que se puedan utilizar en el sistema.

Pantalla de Registro

Son aquellos formularios para registrar los parámetros necesarios para


generar o actualizar información y permitir llevar a cabo las operaciones y
transacciones del sistema.

En estos formularios se cuenta con la botonera básica según sea el


caso (guardar, cancelar), ubicada en la parte inferior centrada. El contenido según
sea el caso responde a las distintas necesidades de información que amerite
el formulario.

88
Figura 20.Pantalla de Registro.

Pantalla de Transacción

Son aquellos formularios que involucran información de dos o más


tablas, compuestos por una estructura compleja que permite usar información
básica registrada previamente que para el sistema, sirve de apoyo a los
procesos, que facilitan las operaciones diarias y comunes realizadas,
inherentes a las gestiones académicas, de instrumentos y de eventos.

89
Figura 21.Pantalla de Transacción.

Pantallas de Reportes

El sistema de información Bambú incorpora en sus componentes, un


módulo de reportes que permitirán generar en base a información registrada y de
acuerdo a ciertos criterios establecidos, la información organizada y agrupada, que
permita potenciar y dar soporte a las toma de decisiones de los diferentes usuario
que tengan privilegios a ella. Dentro de los cuales se presentarán de tipo: Básicos,
que brindan al usuario información referente a las entidades maestras de la base
de datos. Transaccionales, que brindan al usuario información referente a las
diferentes operaciones asociadas a las gestiones . Estadísticos, que mediante
tablas y gráficos muestran el comportamiento de las gestiones inherentes al
sistema.

90
Todos los reportes que se pueden generar, pueden ser en caso de ser
necesario preparados en formatos para impresión inmediata o respaldar
mediante el formato de documento digital.

Reportes Estructurados

Para ingresar a esta pantalla, debe ir a la dirección en el menú donde están


los reportes y luego seleccionar “Estructurados” en el menú del sistema.

En esta pantalla, el usuario debe seleccionar sobre que parte del sistema
desea realizar un reporte estructurado, esto lo puede seleccionar haciendo clic en
el botón abrir, donde se mostrarán todas las opciones posibles para realizar esta
clase reporte. Si por alguna razón, el usuario desea no completar este proceso,
puede salirse de la pantalla haciendo clic en el botón cancelar.

91
Reportes no Estructurados

Para ingresar a esta pantalla, debe ir a la dirección en el menú donde están


los reportes y luego seleccionar “No Estructurados” en el menú del sistema. En
esta pantalla, el usuario debe seleccionar sobre que parte del sistema desea
realizar un reporte no estructurado, esto lo puede seleccionar haciendo clic en el
botón, donde se mostrarán todas las opciones posibles para realizar esta clase
reporte. Cuando haya seleccionado esto, el usuario debe proceder a hacer clic en
el botón generar reporte.

Reportes Estadísticos

El usuario puede generar diferentes tipos de estadísticos, para ello, debe ir


a la dirección en el menú donde están los reportes y luego seleccionar la opción
del estadístico que desee en el menú del sistema. Al hacer esto, se muestran las
siguientes pantallas, dependiendo de la opción que el usuario haya escogido.

Mensajes

Son las distintas visuales que interactúan con el usuario, minimizando la


incertidumbre de los resultados o proceso de las operaciones realizadas.

Mensaje de información

Mensaje mostrado cuando el usuario intenta modificar un registro cuando


no hay uno seleccionado.

92
Mensaje de Confirmación

Mensaje que el usuario ve cuando crea un registro y este se guarda


con éxito en la base de datos.

Mensaje de Error

Mensaje de error que aparece al usuario cuando intenta eliminar un


registro que tiene información asociada a él.

93
CAPITULO V
DESCRIPCION DE LOS MODULOS

DEL SISTEMA

94
Descripción del Capitulo

En la presente sección se desplegará toda la navegación del


proyecto, de manera que se puedan detallar todos los formularios
disponibles, de acuerdo a las gestiones involucradas. Además de incluir los
reportes inmersos en el sistema.

Modulo del Sistema (Portal Web)

El portal web tienen como funcionalidad mostrar a los usuarios no


registrados toda la información referente a la organización así como también todos
los servicios que ofrece Spinetti Spa Gym, por lo cual podrá solicitar su primera
cita que será la consulta diagnóstico, la cual arrojará como resultado los servicios
por los cuales puede optar.

Inicio

En esta vista del portal web, se muestran las diferentes funciones del
sistema en Base a las tareas principales del sistema Bambú; las cuales se
encuentran divididas por partes. En la página principal las imágenes serán
dinámicas.

Parte Superior Derecha


Se encuentra un panel que contiene el logo de Bambú a la izquierda y
los distintos opciones que ofrece la organización.

Parte central
En medio del portal web encontraremos unas imágenes que son
dinámicas y una opción de ver más.

95
Parte inferior
En esta sección se detalla la cartelera informática Foster y los iconos de
síguenos en nuestras redes, Tweets además del horario de trabajo.
Inicio
Tendrá un slider principal donde se colocan promociones e información
relevantes que Spinetti Laser que considere importantes.

Figura 20.Caroussel Principal.

Una opción que te lleva a la descripción.

96
Figura 21.Parte Inferior del caroussel.

Cartelera Informativa
En la parte inferior tendrán una cartelera donde se publicaran las
noticias.

97
Figura 22.Parte Inferior del caroussel.

Footer
Este estará ubicado en la parte inferior de la página principal, se visualizara
las imágenes de síguenos en nuestras redes, además del horario de trabajo.

Figura 23. Footer de la página principal.

Servicio
Se encuentran los distintos servicios que ofrece la organización donde tiene
un ver más y se puede ver con detalle cada uno. Entre ellos: Corporal, Cavitación
etc.

98
Figura 24. Servicios prestados.

Paquete

Tendrá un slider con cada paquete que ofrece la organización.IPL,


Radiofrecuencia Fraccionada, Eliminación de Tatuajes, Masoterapia, Cavitación,
Presoterapia, Depilación Definitiva, Bronceado ,Medicina China: Ventosas,
Aromaterapia, Auriculoterapia, Limpieza de Cutis, Servicios de Sauna y Vapor.

99
Figura 25.Paquetes que ofrece la organización.

Nosotros:

Estará una breve descripción de la organización, Misión, Visión, Objetivos,


Sobre nosotros.

Figura 26.Nosostros la Organización.

100
Figura 27.Vision, Misión, Objetivos.

Figura 28.Objetivos.

101
Figura 29. Sobre nosotros.

Reserva

Esta opción va vinculada con la consulta diagnostica, debe solicitarla


antes de cualquier servicio donde se ingresa sus datos (Nombre, Apellido, Correo
etc.), además se le pregunta porque medio es referida hacia Spinetti. Se ingresa
los datos acerca de la cita (Selecciona fecha, hora, y el esteticista). Además del
Twitter.

102
Figura 30. Datos personales para la reservación.

Formulario para los datos de la cita.

Figura 31.Formulario de los datos de la cita..

103
Figura 32. Formulario de los datos de la cita.

Contacto

En esta pantalla, se puede visualizar los datos para contactar a Spinetti


Laser, allí se muestran la dirección donde están ubicados, número telefónico,
correo electrónico y sus redes sociales. Además le muestra al usuario un pequeño
formulario para poder contactarlos desde el portal web, una vez ingresados los
datos solicitados el usuario.

104
Figura 33. Dirección y Mapa de Ubicación.

Una vez ingresado a la página, ingresamos los datos personales, luego siguiente.

Figura 34. Dirección y Mapa de Ubicación.

105
Una vez ingresado los datos nos vamos al botón de mensaje, donde
estará vinculado motivo del mensaje, servicio y especialidad luego le das enviar.

Figura 35. Formulario sobre motivo del mensaje.

Preguntas

Aquí se realizaran preguntas, dudas y sugerencias será infiltrado


servicio, instalaciones.

106
Figura 36. Formulario sobre preguntas frecuentes.

Redes Sociales
En esta sección del portal web se puede tener un contacto más cercano
a las actividades que se realizan en Spinetti gracias al uso de las redes sociales.
Esta sección se encarga de mostrar la última actividad que hubo en las redes
sociales más populares que maneja la organización.

Instagram

En esta sección, se puede visualizar la actividad que tiene Spinetti Laser


en su cuenta de Instagram. Aquí el usuario puede interactuar con la organización
teniendo acceso a las fotos y comentarios llevados a cabo por la organización.
@grupo_spinetti

107
Figura 37. Instagram Del Grupo Spinetti.

Twitter

En esta sección, se puede visualizar la actividad reciente en el twitter de


Grupo Spinetti, donde el usuario podrá interactuar con la organización y podrá
tener acceso a las fotos y comentarios llevados a cabo por la organización.

108
Figura 38. Twitter Del Grupo Spinetti.

Facebook
En esta sección, se puede visualizar la actividad reciente en Facebook de
Grupo Spinetti, donde el usuario podrá interactuar con la organización y podrá
tener acceso a las fotos y comentarios llevados a cabo por la organización.

https://www.facebook.com/Grupo-Spinetti-206454879784638/

109
Figura 39. Facebook Del Grupo Spinetti.

Modulo del Sistema (Intranet)

En este componente esta brindado a los usuarios que tienen que ver con
los procesos del negocio tales como clientes, recepcionista, gerentes y esteticista,
ellos tendrán acceso a las distintas gestiones a reportes, configuraciones también
a información estadística y todo dependerá del permiso que le sean otorgados a
cada uno de ellos. El sistema web desktop representa el componente principal
este permitirá realizar todas las gestiones principales de la organización, como la
gestión de clientes, agenda y servicios, además de controlar la gestión de difusión
y escucha al cliente, gestión de configuración y parametrización, gestión de
seguridad y otras funcionalidades que den respuesta a las gestiones de apoyo que
maneja la organización. Desde este componente serán enviados a los clientes
todas las notificaciones hacia la aplicación móvil acerca de su próxima cita y
tratamientos.

110
En la sección “Inicia Sesión” los usuarios que se encuentren registrados
en el sistema tienen la opción de ingresar al sistema de acuerdo a su rol, al
ingresar su usuario y su contraseña para acceder a las principales funciones del
sistema Bambú.

Figura 40. Inicia Sesión.

Una vez que el usuario haya seleccionado la opción “Inicia Sesión”


ingresara a la página principal del sistema Bambú. SSE

Figura 40. Botón Iniciar Sesión para ingresar al Sistema.


.

111
En cuanto el usuario cumple con los pasos anteriores, el sistema se
encarga de hacer la validación de sus datos, y, en caso de estar todo correcto,
lleva al usuario a la siguiente pantalla.

Figura 41. Pantalla Principal.

Las funciones del menú que se muestran varían de acuerdo a los permisos
que posea el usuario, dichos permisos solo pueden ser otorgados única y
exclusivamente por los miembros de la organización, eso siempre y cuando
tengan el permiso para realizar tal acción. Dependiendo de su rol.

Manejo del Menú Principal:

Esta opción del menú le permite al usuario del sistema, visualizar , y


realizar distintas acciones , por lo cual el menú es distinto entre usuarios

112
con distintos roles. Está organizado de la siguiente manera buscando que
el usuario tenga un recorrido más grato dentro del sistema:

Figura 42. Menú Pantalla Principal.

Para que el usuario entienda cada una estas de estas funciones,


se pasarán a definir a continuación dichas funciones:

 Mi Perfil
Aquí el usuario tiene dos opciones para seleccionar, datos personales o
preferencias.

113
Figura 43. Menú MI Perfil.
Datos Personales

Esta opción del menú le permite al usuario del sistema, visualizar su


perfil, y realizar distintas acciones con dicho perfil, como modificar sus datos
básicos, Ubicación. Además en la opción “perfil” en el menú superior derecho,
está también la opción “cerrar sesión” la cual le permite al usuario salir de su
sesión actual y cerrarla. Esto quiere decir, que cuando ingrese nuevamente al
sistema, debe de volver a introducir sus datos para acceder al sistema.

Parte Inferior del formulario

114
Figura 44. Datos Personales.

Partes Inferior del Formulario

Figura 45. Datos Personales.

115
En esta sesión una vez llenado los datos seleccionar Editar.

Usuario
Esta opción del menú le permite al usuario del sistema, visualizar su
perfil, y realizar distintas acciones con dicho perfil, como modificar sus datos
básicos,.
En esta sesión el usuario obtiene su usuario y contraseña puede ingresar
al sistema. Entran con un correo una contraseña, rol, confirma contraseña podrán
Editar, Cancelar.

Figura 46. Usuario.

Preferencias

116
En esta sección el usurario podrá seleccionar las preferencias de acuerdo al
gustos de cada cliente en materia de información para los servicios de prestación
de la organización, y los mismos tendrán relevancia para una atención
personalizada , para que así experimenten niveles únicos de armonía mente-
cuerpo, salud y belleza. Seleccionar Guardar.

Figura 47. Gustos, Preferencias.

 Cliente
Esta área tiene como objetivo conocer las distintas necesidades de los
clientes para orientar los servicios que ofrece Spinetti Laser y garantizar una
excelente atención. En esta sesión el usuario tendrá la opción de llenar la ficha
correspondiente a los datos básicos, y solicitar la consulta diagnostica.

117
Figura 48. Menú Clientes.

Ficha del Cliente

En esta sesión el usuario podrá ingresar los datos personales del cliente
una vez llenada esta ficha seleccionar Guardar o Cancelar.

Figura 49. Ficha del Clientes.

118
Servicio Recomendado

En esta sesión el usuario se podrá visualizar cuáles son lo servicio


recomendados, después de su consulta diagnóstica.

Figura 50. Servicio Recomendados.

 Consulta Diagnostica

El cliente solicita su primera cita, así como también solicita que tipo de
servicio desea recibir de los prestados por el Spinetti Laser. Se visualizaran los
datos del cliente, Necesidades, Información (Hábitos, Antecedentes, Test).
Además de servicios recomendados seleccionar Guardar o Cancelar.

119
Figura 51. Consulta Diagnostica.

 Agenda

En esta Área la Agenda forma parte de los procesos medulares de la


organización en cuestión, representando las actividades principales que se llevan
a cabo. Tiene como objetivo Garantizar una atención programada y controlada de
los servicios ofrecidos en Spinetti Laser para el disfrute de los clientes.

Figura 52. Menú Agenda.

120
Ver agenda

Solicitar Cita

El cliente solicita su primera cita, así como también solicita que tipo de servicio
desea recibir de los prestados por el Spinetti Laser, donde se suministra los datos
del cliente y la fecha en la que desea asistir, la misma se asigna dependiendo de
la disponibilidad de los esteticistas.

121
Figura 53. Solicitud de Cita.
Se visualizaran datos del clientes además la hora , esteticista y el cubículo
donde estará.

Mis Citas

En esta sesión es, donde se suministra los datos del cliente y la fecha en la
que desea asistir, la misma se asigna dependiendo de la disponibilidad de los
esteticistas asigna la fecha, la hora en que el cliente solicitó la cita y el servicio
solicitado.

122
Figura 54. Mis Cita.

 Servicio

El Área de Gestión de Servicios forma parte de los procesos medulares de


la organización en cuestión, representando las actividades principales que se
llevan a cabo en ella. Tiene como objetivo ofrecer una gama de servicios que
brinde una experiencia única de relajación y armonía que lleven a nuestros
clientes a sentirse en un estado de bienestar tanto interno como externo todo esto
mediante tratamientos de estética y salud.

123
Figura 55. Menú de Servicio.
Registrar Sesión
En esta sesión se registran la sesión de cada cliente sus datos, el servicio
adquirido por el mismo con la finalidad de llevar un mejor manejo de la información
en cuanto a los indicadores o paquetes que se ha realizado en Spinetti Laser.

Figura 56.Registrar Sesión.

124
Ver Avances
En esta sesión se registran los servicios o tratamientos que el cliente se
realizó para crearle su historial y poder darle un seguimiento a los mismos.

Figura 57.Avances de Servicio.

 Alianzas y Convenios

Esta sesión trata de las alianzas y convenios el tipo de acuerdo además


de las lista de acuerdos que tiene la organización con otras empresas.

125
Figura 58.Menu Alianza y Convenio.

En esta sesión se registraran los acuerdos y convenio con otras


organizaciones, para el intercambio de servicios.

Figura 59.Alianza y Convenio.

 Canal Escucha Cliente

En esta sesión, los usuarios podrán realizar sugerencias y comentarios


creando un canal directo de difusión y escucha al cliente proporcionando
información relevante para los servicios prestados por el Spinetti Laser además
permitir conocer las necesidades y opiniones de los mismos, con la intención de
generar información que apoye a la toma de decisiones gerenciales sobre los
servicios prestados, así como también poder difundir promociones y servicios
basado en los gustos y preferencias individuales.

126
Figura 60. Menú Canal de Escucha.

Bandeja de Comentario

En esta sesión los usuarios podrán realizar los comentarios que a su vez
dan opiniones como sugerencias propias, dudas, opiniones.

Figura 61. Bandeja de Entrada.

En esta sesión tendrán la opción de responder.

127
Figura 62. Bandeja de Responder.

 Difusión

En esta sesión, es donde se manipulara cartelera informativa y buzón de


sugerencias, en el cual los clientes o clientes potenciales podrán dar sus
sugerencias o solicitar información de los servicios o tratamientos que ofrece
Spinetti Laser.

128
Figura 63.Menu Difusión.

Noticia

Esta área es referente al caso de cualquier eventualidad que ocurra, esta


podrá ser difundida para que los clientes puedan estar al tanto y tomar
previsiones.

Registrar Noticia

En esta sesión se registrara el tipo de noticias que serán presentadas en la


cartelera informativa, y que también podrán desvincularse, aparte de registrar las
opiniones de los usuarios también se realizan modificaciones a las imágenes, se
obtendrá información de las necesidades de los clientes.

129
Figura 64.Registrar Noticia.

Promociones

En esta sesión, se podrán registrar información de promociones que


tengan que ver con Spinetti Laser como promociones de servicios a través de
paquetes. Fecha de Inicio y Finalización.

Figura 65.Registro de Promoción.

130
Notificaciones

En esta sesión recibirían notificaciones personalizadas para la solicitud de


tratamientos a través de sus gustos y servicios ya realizados en Spinetti Laser. De
igual manera los clientes podrán recibir notificaciones de confirmación de citas,
luego seleccionar Guardar.

Figura 66.Registro de Notificación.

 Horario

En esta sesión se registraran los horarios de acuerdo a cada esteticista y


los bloques laborables por día.

131
Figura 67.Menu de Horario.

Esteticista

En esta sesión se visualizara el horario del esteticista y los bloques de cada


día.

132
Figura 68. Horario de Esteticista.

Cubículo

En esta sesión se visualizaran el horario de cada equipo con cada día


laborable. Además de los bloques.

133
Figura 69. Horario de Equipo.

 Consultas y Reportes

En esta sesión se visualizaran los reportes estructurados y estadísticos


referentes a la organización. Los cuales son de apoyo a la toma de decisiones.

134
Figura 70. Menú Consultas y Reportes.

 Configuración
En esta sesión se visualizan los datos referentes a la organización.

Figura 73. Menú de Configuración.

Organización
En esta sesión van registrados los datos básicos de la organización, se
podrán modificar al igual que la imagen .Seleccionar Guardar.

135
Figura 74. Registrar Organización.

Filosofía de la Organización

En esta sesión se registrara la filosofía de la organización, tipo de objetivos y


además podrán visualizar una lista de objetivos que podrán Agregar luego
seleccionar Guardar.

Partes Superior

136
Figura 75. Registrar Organización.
Parte Inferior

Figura 76. Registrar Organización.

137
Redes Sociales
En esta sesión es donde se registran el tipo de redes sociales de la
organización.

Figura 77. Registrar Redes Sociales.

Slider

En esta sesión se registran las imágenes de la página de la organización.

138
Figura 78. Registrar Imágenes Slider.

General

Figura 79.General.

139
Tablas Básicas
En esta sesión estarán los maestros.

Figura 80.Menu de las Tablas Básicas.

Cliente
En estas sesiones se visualizaran todos los maestros.

Figura 81.Menu Cliente.

140
Necesidad

En esta sesión le permite registrar información del usuario referente a su


necesidad.

Figura 82.Registrar Necesidad.

Preferencia

Se registran las preferencias que tiene el cliente respecto a los


tratamientos, para así poder hacerle llegar notificaciones de su interés.
Seleccionar. Guardar o Cancelar.

Parte Superior

141
Figura 83.Registrar Preferencia.
Parte Inferior

Figura 84.Registrar Preferencia.

142
Indicador de Diagnostico

En esta sesión se visualizaran el indicador diagnostico por servicio y su


descripción.

Figura 85.Indicador del Diagnostico por servicio.

Ocupación

En esta sesión es referente a la ocupación que tenga disponible el cliente


se le asociara un servicio.

143
Figura 86.Ocupacion por servicio.

Habito
En esta sesión el hábito del cliente será asociado a un servicio.

Figura 87.Habito por Servicio.

144
Antecedentes
En esta sesión el antecedente de cada cliente va asociado a un servicio.

Figura 88.Antecedente por Servicio.

Referencia

En esta sesión se registran la referencia por la cual el cliente fue referido hasta
la organización.

145
Figura 89.Registrar Referencia.

 Agenda

Son Maestricos en esta se selecciona la opción requerida y luego se le da


Enter. Como son los formularios, Registrar Días Laborables, Bloque y Registrar
Motivo de Cancelación. Ejemplo.

146
Figura 90.Registrar Días Laborables.

 Servicio
En esta el formulario Maestricos se llena los campos necesarios luego se
selecciona Enter. Entre estos están, Cubículo Por Servicio. Ejemplo:

147
Figura 91.Cubiculo Por Servicio.

Los Maestros como Registrar Servicio, Registrar Paquete, Avance de


Servicio, Incidencia, se llena la campo necesario luego podrán seleccionar
Guardar o Cancelar.

148
Figura 92.Registar Avance.

 General

En este Formulario se registran las preguntas de encuestas, el tipo podrás


Guardar o Cancelar.

149
Figura 93.Registar Pregunta de Avance.

Repuesta de Encuesta

En este formulario se selecciona la repuesta y luego se actualiza.

150
Figura 94.Registar Repuesta.

 Parámetros
En esta sesión los Maestricos se seleccionan la opción requerida luego
seleccionar Enter. Entre ellos están: Registrar Tipo de Cliente, Registrar Tipo de
Incidencia, Registrar Tipo de Red Social, Registrar Tipo de Notificación,

Figura 95.Menu Parámetros.

151
Maestricos

Figura 96.Registrar Tipo de Incidencia.

Los Maestros se llenan los campos luego seleccionar Guardar o Cancelar.


Entre ellos están: Registrar Tipo de Servicio, Registrar Tipo de Noticia.

152
Figura 97.Registrar Tipo de Servicio.

 Seguridad Funcional

Figura 98.Menu Seguridad Funcional.

153
Rol.
Según su rol podrá gestionar los registros como clientes, esteticistas, entre
otros; gestión de citas, reprogramación de cita, seguimiento al cliente y gestión de
configuración en la parametrización del sistema.

Figura 99.Registrar Rol.

Usuarios
En esta sesión se registraran los usuarios, este obtendrá un usuario o
contraseña con el cual podrá ingresar a la web desktop de acuerdo a su rol.

154
Figura 100.Registrar Usuario.

Permisologia

El acceso a las funcionalidades será de acuerdo a la permisologia otorgada


a los distintos roles en la configuración del sistema. Esta opción del menú le
permite al usuario del sistema (que cuente con los permisos para ello) editar
los permisos de acceso al sistema asignados al determinado tipo de usuario, en la
base de datos del sistema Bambú.

155
Figura 101.Asignar Opciones por Rol.

Respaldo y Recuperación
Depuración Base de Datos
Esta opción del menú le permite al usuario (que cuente con los
permisos necesarios para ello) depurar los registros guardados en la base
de datos de Bambú de las siguientes tablas: noticias, comentarios y
notificaciones.

156
Figura 102.Depuracion de la Base de Datos.

El usuario debe seleccionar las tablas a las que desea depurar, si desea
hacerle depuración a todas las tablas, puede hacer clic en el botón agregar todas
o pasar una a una las tablas haciendo clic en el botón agregar una. Si el usuario
decide no hacerle depuración a todas las tablas seleccionadas, puede hacer clic
en el botón remover una o puede removerlas todas haciendo clic en el botón
remover todas.

Cuando el usuario este contento con las tablas seleccionadas a


depurar, debe hacer clic en el botón Depurar para que se realice le proceso de
depuración.

Noticias:
Se depurarán todos aquellos registros en el que la fecha de publicación
haya Caducado.

157
Respaldo de la Base de Datos

Esta opción del menú le permite al usuario del sistema, que cuente
con los permisos para ello, hacer un respaldo de la base de datos del sistema
Bambú.

Figura 103.Repaldo de la Base de Datos.

El usuario debe seleccionar las tablas a las que desea respaldar, si


desea hacerle respaldo a todas las tablas, puede hacer clic en el botón agregar
todas o pasar una a una las tablas haciendo clic en el botón agregar una
.
Si el usuario decide no hacerle respaldo a todas las tablas
seleccionadas, puede hacer clic en el botón remover una o puede removerlas
todas haciendo clic en el botón remover todas Cuando el usuario este contento
con las tablas seleccionadas para respaldar, debe hacer clic en el botón
respaldar para que se realice le proceso.
.

158
Importar Registro Desde Excel

Esta opción del menú le permite al usuario del sistema (que cuente
con los permisos para ello) cargar un archivo con la información de los voluntarios
a la base de datos del sistema Bambú.

..

Figura 104.Importar de la Base de Datos.

En la pantalla se observa que muestra si desea cargar los datos


desde un archivo debe hacer clic en el botón importar, a continuación se
selecciona el archivo que desea importar o Cancelar.

Restauración de la Base de Datos

Esta opción del menú le permite al usuario del sistema, que cuente con los
permisos para ello, hacer una restauración de la base de datos del sistema
Bambú.

159
Figura 105.Restauracion de la Base de Datos.

El usuario debe seleccionar las tablas a las que desea restaurar, si desea
hacerle restauración a todas las tablas. En la pantalla se observa que
muestra si desea cargar los datos desde un archivo debe hacer clic en el botón
Restaurar o Cancelar, a continuación se selecciona el archivo que desea
restaurar.

160
CAPITULO VI
Aplicación Móvil

161
Descripción del Capitulo

Este capítulo describe la aplicación móvil del sistema Bambú, donde


puntualizan los estándares de presentación y programación utilizados para
desarrollar la aplicación, así como también la descripción de las distintas
funcionalidades que la conforman.

Alcance

El componente móvil del sistema Bambú la organización Spinetti Laser, se


basa principalmente en la difusión de escucha al cliente, en registrar y recibir
notificaciones personalizadas. Los principales procesos que maneja este sistema
son, la gestión de Difusión y Escucha al Cliente.

Figura 106.Procesos Fundamentales y de Apoyo.

Gestión de Difusión y Escucha al Cliente


Esta se encuentra incluida en las gestiones antes nombradas, es acá donde
se manipulara cartelera informativa y buzón de sugerencias, en el cual los clientes
o clientes potenciales podrán dar sus sugerencias o solicitar información de los
servicios o tratamientos que ofrece el Spinetti laser. Además será posible registrar
noticias que serán presentadas en la cartelera informativa, y que también podrán
desvincularse, aparte de registrar las opiniones de los usuarios también se

162
realizan encuestas con las cuales se obtendrá información de las necesidades de
los clientes.

El proceso Gestión de Difusión y Escucha al Cliente, le brinda tanto al


usuario registrado como al no registrado noticias relevantes sobre la organización,
así como también ofrece al usuario registrado emitir comentarios, al mismo tiempo
que recibe notificaciones personalizadas.

El sistema móvil fue implementado en el lenguaje nativo Android


buscando así mayor usabilidad de esta aplicación.

Objetivos Generales

Proporcionar información oportuna y útil además de un canal de


interactividad con las noticias sobre Spinetti Laser, permitiendo a los clientes
recibir notificaciones personalizadas, así como también brindar un mecanismo de
escucha para mantenerlos activos, aumentar el sentido de pertenencia y
permanencia prolongada en la organización.

Objetivos Específicos

Ofrecer un canal de difusión y escucha al cliente que permita conocer las


necesidades y opiniones de los mismos, con la intención de generar información
que apoye a la toma de decisiones gerenciales sobre los servicios prestados por
Spinetti Laser, así como también poder difundir promociones y servicios basado
en los gustos y preferencias individuales.

En la aplicación móvil, los usuarios podrán realizar sugerencias y


comentarios creando un canal directo de difusión y escucha al cliente

163
proporcionando información relevante para los servicios prestados por el Spinetti
Laser para su crecimiento y mejora continua. Recibirían notificaciones
personalizadas para la solicitud de tratamientos a través de sus gustos y servicios
ya realizados en el Spinetti Laser. De igual manera los clientes podrán recibir
notificaciones de confirmación de citas. A través de la aplicación móvil podrá
realizarse con mayor comodidad la cancelación de citas por asuntos del cliente.

Plataforma Computacional
Arquitectura del Software Móvil

Para desarrollo de la aplicación móvil se usó Android Studio, siendo


este un entorno de desarrollo integrado para el sistema operativo Android lanzado
por Google, diseñado para ofrecer nuevas herramientas para el desarrollo de
aplicaciones y alternativa al entorno Eclipse, hasta ahora el IDE más utilizado. El
mismo cuenta con la herramienta de soporte Grande que permite la
automatización en la construcción de proyectos, manejando entre otras cosas,
lo que son las tareas de compilación.

La aplicación móvil será desarrollada en Android Nativo, en su Framework


Android Studio, haciendo uso de SQlite, SDK, Json y Rest Template, lo cual
permitirá una visualización a través de dispositivos que utilicen una versión mínima
de Android 4.0.3.

Se utilizaran servicios web que permitirán la conexión del sistema web


desktop, la aplicación móvil y el portal web con la base de datos.

La base de datos permitirá el registro de todos los datos para dar


respuestas oportunas a todas las solicitudes de información por parte de los
usuarios y la aplicación móvil. Se utilizara como gestor de base de datos
PostgreSQL.

164
Herramientas Utilizadas:
 Java 8,
 IDE Eclipse Kepler,
 SDK,
 Apache Tomcat,
 PostgreSQL,
 Maven,
 Gson.
 GitHub

Estándares de Aplicación Móvil

Estándares de Programación

Estándares de Java Android Studio

Estructura general del proyecto

Sección App
Dentro de la carpeta
App
encontraremos todo lo
referente a
los modelos, vistas y
controladores
de nuestra aplicación
separado
en 3
módulos: “manifest”, “java” y
“res”
Módulo res
Módulo encargado de tener
todo lo referente a las vistas.
En este módulo
encontraremos las siguientes
carpetas:

165
drawable: Carpeta donde
se deben guardar todos
los iconos de la aplicación
excepto el principal, efectos
Visuales, estilos a los
componentes gráficos como
botones, etiquetas, entre
otras.

layout: Carpeta donde se


encontrará todas las vistas de
la aplicación en archivos con
extensión .xml. Además
también encontraremos las
capas de una vista cualquiera
en el caso de que se
desarrolle bajo los esquemas
de vistas por capas (esquema
material desing).

menú:
Carpeta encargada de
almacenar todos los diferentes
Menús de la aplicación en
archivos .xml. En ella tendrá
los
menús convencionales de
Android y los menos tipo
NavDrawer(menús que se
despliegan de los
Bordes de la App).

mipmap: En esta carpeta


Encontraremos en diferentes
tamaños él .png referente
al icono principal de la App.

values: En esta carpeta


encontraremos todos los
valores estáticos de la
aplicación como: las
etiquetas String, colores,
Temas de la app, entre
otros valores estáticos.

166
Sección Gradle Script
Sección encargada de
manejar las diferentes
Librerías que nuestro proyecto
consume. Gradle en Android
Studio es un manejador de
librerías que funciona
obteniendo la url (repositorio
de la librería) y este los
descarga y los ubica dentro
de su carpetas para un
posterior uso, esto lo hace
básicamente a través de los
archivos: build.gradle (del
proyecto), build.gradle (del
módulo App) y setting.gradle
del proyecto.
DTO
En esta carpeta son las clases
modelos.

Calificación En esta carpeta


Van los controladores.

Tabla 3. Estándares de Programación Móvil

167
Estándares De Presentacion.
Menú
Bambú Móvil cuenta con un menú lateral desplegable de izquierda a
derecha que contiene todas las opciones a realizar por el usuario. Es un menú
dinámico presentado de manera vertical y se puede visualizar una vez que el
usuario inicie sesión. Está compuesto en dos partes:

 La parte superior la cual posee un fondo estándar con el logo del nombre
de la aplicación, además donde se puede observar la foto de perfil
del sistema..

 La parte inferior en la cual se encuentran las opciones que el


usuario puede realizar dentro de la aplicación.

Figura 107.Menu de la Aplicación Móvil.

168
 El color y tamaño de la fuente son los predeterminados por el Android
Studio, resaltando en color verde el ítem seleccionado.
 Los títulos y subtítulos del menú deben tener también el formato
predeterminado por el Android Studio.

Menú Antes de Iniciar Sesión

Se encuentra en la pantalla principal del sistema de forma horizontal en la


parte superior, de color verde ,el cual tiene las siguientes opciones el
nombre de la aplicación, una opciones donde aparece promociones, nuevos
paquetes y conoces nuestro servicios. Seleccionar INICIAR SESION.

Figura 108.Menu antes de Iniciar Sesión.

169
Al pulsar el botón de Promociones se visualizaran los detalles de las promociones
que estén en ese momento.

Figura 109.Detalle. Figura 110.Detalle Paquete.

Al iniciar sesión pedirá un usuario y una contraseña luego INICIAR SESION.

Figura 111. Iniciar Sesión.

170
En la parte superior se observa una franja color verde en la que
destacan, el nombre de la aplicación, un botón de alera de nuevas noticias.

Figura 112. Pantalla Inicial. Figura 113. Pantalla con las Opciones.

 Mis Citas

En esta opción se visualizarán las citas, que estén planificadas para ese
día.

Figura 114. Mis Citas. Figura 115. Cita Programada.

171
 Notificaciones

Según los gustos y preferencias se crean las notificaciones personalizadas


para que cada cliente las reciba.

Figura 116. Notificaciones Personalizadas.

 Contáctanos

En esta opción se visualiza el servicio que desea. Seleccionar ENVIAR.

172
Figura 117. Contacto.

Accesibilidad

El acceso a las distintas secciones del sistema por medio de botones


puede hacerse de manera táctil.

Apariencia

Se especifican los elementos presentes en las pantallas de Bambú,


así como su función dentro del mismo.

Campo de texto o Numérico

Permite la escritura a través del teclado de algún valor requerido para


las funcionalidades de las interfaces. Este tipo de componente presente en
las interfaces varía de acuerdo al requisito que se desea leer, existe uno para
campos de texto y otro para campos numéricos. Además cuenta con una marca
que indica al usuario que debe escribir. En forma y estructura son los mismos.

173
Figura 118. Campo de Texto o Campo Numérico.

Lista de Botones con sus respectivas representaciones grafica

Descripción Representación Grafica


Botón para actualizar Noticias o
Notificaciones.

Botón para acceso a la pantalla de


Login.

Botón de acceso al Menú.

Botón de Confirmación

Botón de Cancelar

Tabla Nº 2. Lista de Botones.

174
Navegabilidad de la Aplicación

Portal Inicial

Es la primera visual que se le presenta a cualquier usuario, en


el instante que descarga la aplicación y se le da puesta en marcha.

Figura 119.Pantalla Inicial.

Pantalla de Inicio de Sesión

En esta pantalla con un usuario y contraseña puede iniciar sesión


en la aplicación y tener acceso a las distintas funcionalidades ofrecidas
para usuarios de la aplicación móvil, colocando su usuario y contraseña,
además de presionar Iniciar Sesión. Además cuenta con la opción de ver
contraseña con el fin de que el usuario pueda verificar la escritura
correcta de la misma.
175
Figura 120.Pantalla de Inicio de Sesión.

Pantalla Principal después de Iniciar Sesión

Esta pantalla contiene el lisado de noticias generadas sobre la


organización además cuenta con un botón que despliega el menú de la
aplicación para los usuarios.

176
Figura 121.Pantalla Principal luego de Inicio de Sesión.

Menú

En esta pantalla se encuentran las distintas opciones que direccionan


a las funcionalidades inherentes al voluntario. Arrastrando al lado izquierdo de
la pantalla el menú vuelve a ocultarse mostrando de nuevo la pantalla
principal.

El menú muestra en su parte superior la Nombre, del usuario la y


Usuario del Voluntario y debajo todas las opciones a las que puede acceder,
como lo son:

177
Figura 122.Menu.

178
CAPITULO VI
DESCRIPCION DE LA BASE DE
DATOS

179
Descripción del Capitulo

En este capítulo se define la estructura de la bases de datos mediante un


modelo entidad-relación, para representar la estructura estática de Bambú,
mostrando los objetos del sistema, representados por entidades y las relaciones
entre la mismas.

Finalmente, se provee un listado de las 88 tablas que componen la base de


datos, cada una con un respectivo detalle, donde se muestra la descripción de
cada tabla.

180
Modelo Lógico de Datos (MER)

Figura 124.Modelo Lógico de Datos.

181
Listado de Tablas

tb_agenda

tb_antecedente

tb_antecedente_cliente

tb_antecedente_servicio

tb_avance

tb_avance_servicio

Tb_bloque

tb_calificacion

tb_cita

tb_ciudad

tb_cliente

tb_comentario

tb_comentario_cubiculo

tb_comentario_estesticista

tb_comentario_organizacion

tb_comentario_servicio

tb_cubiculo

182
tb_cubiculo_servicio

tb_detalle_avance

tb_detalle_paquete

tb_detalle_sesion

tb_detalle_solicitud

tb_dia_laborable

tb_diagnostico

tb_disponibilidad_esteticista

tb_disponibilidad_cubiculo

tb_estado

tb_esteticista

tb_formulario

tb_formulario_cliente

tb_formulario__web_cliente

tb_habito

tb_habito_cliente

tb_horario

tb_horario_cubiculo

tb_horario_esteticista

183
I

tb_incidencia

tb_incidencia_sesion

tb_indicador

tb_indicador_cliente

tb_indicador_diagnostico

tb_indicador_servicio

tb_motivo_cancelacion

tb_necesidad

tb_necesidad_cliente

tb_noticia

tb_notificacion

tb_objetivo

tb_ocupacion

tb_ocupacion_servicio

tb_opcion

tb_opcion_rol

tb_organizacion

tb_paquete

184
tb_perfil_usuario

tb_preferencia

tb_preferencia_cliente

tb_preferencia_servicio

tb_pregunta

tb_promocion

tb_red_social

tb_referencia

tb_repuesta

tb_repuesta_comentario

tb_repuesta_formulario_web

tb_rol

tb_servicio

tb_servicio_recomendado

tb_sistema

tb_slider

tb_solicitud

tb_tipo__acuerdo

tb_tipo_cliente

tb_tipo_comentario

185
tb_tipo_encuenta

tb_tipo_comentario

tb_tipo_incidencia

tb_tipo_noticia

tb_tipo_notificacion

tb_tipo_organizacion

tb_tipo_preferencia

tb_tipo_pregunta

tb_tipo_red_social

tb_tipo_servicio

tb_usuario

tb_usuario_notificacion

tb_usuario_web

Descripción de Entidades

Se describirán las entidades mediante tablas, que expondrán los datos


de la siguiente manera:
 Atributo: Nombre del atributo.
 Descripción: Explicación del atributo.
 Tipo (Longitud): Tipo de carácter en el cual se representará el atributo.
 Clave: De ser el atributo una clave, se especificará que tipo es. Puede ser,
una primary key (PK) o una Foreign key (FK).

186
 Nulo: Representará mediante una “X” si el atributó puede estar nulo. De
estar vacío, indicará que no puede ser nulo.

 Referencia: Indica la tabla a la cual hace referencia el atributo (en caso de


hacerlo).
 Cabe destacar, que cada tabla tiene en la parte superior derecha, un
círculo, de fondo blanco y bordes verdes, con la letra por la cual empieza el
mismo. Este es un link vinculado al listado de tablas, en su sección
correspondiente.

tb_acuerdo
Contiene los datos del acuerdo.

codigo character varying (5) NOT NULL,


nombre_empresa character varying (45),
tipo_acuerdo character varying (5),
codigo_organizacion character varying (10),
status character varying (8),
fecha date,
observacion character varying (500),
CONSTRAINT id_acuerdo PRIMARY KEY (codigo),
CONSTRAINT fk_organizacion_acuerdo FOREIGN KEY (codigo_organizacion)
REFERENCES tb_organizacion (rif)
CONSTRAINT fk_tipo_acuerdo FOREIGN KEY (tipo_acuerdo)
REFERENCES tb_tipo_acuerdo (codigo)

187
tb_agenda
Contiene los datos de la agenda.
codigo character varying (5) NOT NULL,
status character varying (8),
descripcion character varying (45),
codigo_dia character varying (5),
CONSTRAINT id_agenda PRIMARY KEY (codigo),
CONSTRAINT fk_dia_laborable FOREIGN KEY (codigo_dia)
REFERENCES tb_dia_laborable (codigo)

tb_antecedente
Contiene los antecedentes.
codigo character varying(5) NOT NULL,
descripcion character varying(45),
status character varying(8),
CONSTRAINT id_antecedente PRIMARY KEY (codigo)

tb_antecedente_cliente
Contiene los antecedentes por clientes.

codigo_antecedente character varying (5) NOT NULL,


codigo_cliente character varying (10) NOT NULL,
codigo character varying (5) NOT NULL,
status character varying(8),
CONSTRAINT id_antecedente_cliente PRIMARY KEY (codigo),
CONSTRAINT fk_antecedente_cliente FOREIGN KEY (codigo_antecedente)
REFERENCES tb_antecedente (codigo)
CONSTRAINT fk_cliente_antecedente FOREIGN KEY (codigo_cliente)
REFERENCES tb_cliente (cedula)

188
tb_antecedente_servicio
Contiene los antecedentes por servicio.

codigo_maestro character varying (5) NOT NULL,


codigo_servicio character varying (5) NOT NULL,
codigo character varying (5) NOT NULL,
status character varying (8),
CONSTRAINT id_antecende_servicio PRIMARY KEY (codigo),
CONSTRAINT fk_antecedente_servicio FOREIGN KEY (codigo_maestro)
REFERENCES tb_antecedente (codigo)
CONSTRAINT fk_servicio_antecedente_codigo FOREIGN KEY (codigo_servicio)
REFERENCES tb_servicio (codigo)
tb_avance
Contiene los datos del seguimiento.

codigo character varying(5) NOT NULL,


descripcion character varying (45),
status character varying (8),
unidad_medida character varying,
CONSTRAINT id_avance PRIMARY KEY (codigo)
tb_avance_servicio
Contiene los datos del seguimiento del servicio realizado.

codigo_maestro character varying (5),


codigo character varying (5) NOT NULL,
codigo_servicio character varying(5),
status character varying(8),
CONSTRAINT id_avance_servicio PRIMARY KEY (codigo),
CONSTRAINT fk_avance_servicio FOREIGN KEY (codigo_maestro)
REFERENCES tb_avance (codigo)
CONSTRAINT fk_servicio FOREIGN KEY (codigo_servicio)

189
REFERENCES tb_servicio (codigo)
tb_bloque
Contiene los datos de la hora disponible del servicio a realizarse.

codigo character varying (5) NOT NULL,


descripcion character varying (45),
hora_inicio timestamp without time zone,
hora_fin timestamp without time zone,
status character varying (8),
CONSTRAINT id_bloque PRIMARY KEY (codigo)
tb_calificacion
Contiene los datos de la calificacion.
codigo character varying (5) NOT NULL,
codigo_detalle_sesion character varying (5),
puntuacion integer,
CONSTRAINT id_calificacion PRIMARY KEY (codigo),
CONSTRAINT fk_detalle_sesion FOREIGN KEY (codigo_detalle_sesion)
REFERENCES tb_detalle_sesion (codigo)
tb_cita
Contiene los datos de la cita.

codigo character varying (5) NOT NULL,


codigo_detalle_solicitud character varying (5),
codigo_cubiculo character varying (5),
codigo_agenda character varying (5),
status character varying (10),
codigo_motivo_cancelacion character varying (5),
fecha character varying (10),
codigo_esteticista character varying (10),
codigo_servicio character varying (5),
codigo_bloque character varying (5),

190
CONSTRAINT id_cita PRIMARY KEY (codigo),
CONSTRAINT fk_agenda_cita FOREIGN KEY (codigo_agenda)
REFERENCES tb_agenda (codigo)
CONSTRAINT fk_codigo_bloque FOREIGN KEY (codigo_bloque)
REFERENCES tb_bloque (codigo)
CONSTRAINT fk_cubiculo_cita FOREIGN KEY (codigo_cubiculo)
REFERENCES tb_cubiculo (codigo)
CONSTRAINT fk_detalle_solicitud_cita FOREIGN KEY
(codigo_detalle_solicitud)
REFERENCES tb_detalle_solicitud (codigo)
CONSTRAINT fk_esteticista FOREIGN KEY (codigo_esteticista)
REFERENCES tb_esteticista (cedula)
CONSTRAINT fk_motivo_cancelacion_cita FOREIGN KEY
(codigo_motivo_cancelacion)
REFERENCES tb_motivo_cancelacion (codigo) CONSTRAINT fk_servicio
FOREIGN KEY (codigo_servicio)
REFERENCES tb_servicio (codigo)

tb_ciudad

Contiene los datos de las ciudades.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

estado character varying (5),

status character varying (8),

CONSTRAINT id_ciudad PRIMARY KEY (codigo),

CONSTRAINT fk_estado_ciudad FOREIGN KEY (estado)

REFERENCES tb_estado (codigo)

191
tb_cliente

Contiene los datos del cliente.

cedula character varying (10) NOT NULL,

nombre character varying (20),

apellido character varying (20),

sexo character varying (9),

estado_civil character varying (10),

telefono character varying (12),

direccion character varying(100),

correo character varying (45),

ciudad character varying (5),

tipo_cliente character varying (5),

codigo_acuerdo character varying (5),

codigo_referencia character varying (5),

codigo_organizacion character varying (10),

status character varying (8),

codigo_ocupacion character varying(5),

fecha_nacimiento date,

CONSTRAINT id_cliente PRIMARY KEY (cedula),

CONSTRAINT fk_ciudad_cliente FOREIGN KEY (ciudad)

REFERENCES tb_ciudad (codigo)

CONSTRAINT fk_codigo_acuerdo FOREIGN KEY (codigo_acuerdo)

REFERENCES tb_acuerdo (codigo)

CONSTRAINT fk_codigo_ocupacion FOREIGN KEY (codigo_ocupacion)

REFERENCES tb_ocupacion (codigo)

192
CONSTRAINT fk_codigo_organizacion FOREIGN KEY (codigo_organizacion)

REFERENCES tb_organizacion (rif)

CONSTRAINT fk_codigo_referencia FOREIGN KEY (codigo_referencia)

REFERENCES tb_referencia (codigo)

CONSTRAINT fk_tipo_cliente FOREIGN KEY (tipo_cliente)

REFERENCES tb_tipo_cliente (codigo)

tb_comentario

Contiene los datos del comentario.

tipo_comentario character varying (5),

codigo character varying(5) NOT NULL,

descripcion character varying (130),

codigo_usuario character varying (45),

status character varying (8),

codigo_usuario_web character varying (10),

clase_comentario character varying (10),

fecha time with time zone,

CONSTRAINT id_comentario PRIMARY KEY (codigo),

CONSTRAINT fk_codigo_usuario_web FOREIGN KEY (codigo_usuario_web)

REFERENCES tb_usuario_web (cedula)

CONSTRAINT fk_tipo_comentario FOREIGN KEY (tipo_comentario)

REFERENCES tb_tipo_comentario (codigo)

CONSTRAINT fk_usuario_comentario FOREIGN KEY (codigo_usuario)

REFERENCES tb_usuario (usuario)

193
tb_comentario_cubiculo

Contiene los datos del comentario por cubículos

codigo_cubiculo character varying (5) NOT NULL,

codigo_comentario character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying(8),

CONSTRAINT id_comentario_cubiculo PRIMARY KEY (codigo),

CONSTRAINT fk_comentario_cubiculo FOREIGN KEY (codigo_comentario)

REFERENCES tb_comentario (codigo)

CONSTRAINT fk_cubiculo_comentario FOREIGN KEY (codigo_cubiculo)

REFERENCES tb_cubiculo (codigo)

tb_comentario_esteticista

Contiene los datos del comentario por esteticista

codigo_comentario character varying (5) NOT NULL,

codigo_esteticista character varying (10) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying(8),

CONSTRAINT id_comentario_esteticista PRIMARY KEY (codigo),

CONSTRAINT fk_comentario_esteticista FOREIGN KEY (codigo_comentario)

REFERENCES tb_comentario (codigo)

194
CONSTRAINT fk_esteticista_comentario FOREIGN KEY (codigo_esteticista)

REFERENCES tb_esteticista (cedula)

tb_comentario_organizacion

Contiene los datos del comentario por organizacion

codigo_organizacion character varying (10) NOT NULL,

codigo_comentario character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_comentario_oganizacion PRIMARY KEY (codigo),

CONSTRAINT fk_comentario_organizacion FOREIGN KEY (codigo_comentario)

REFERENCES tb_comentario (codigo)

CONSTRAINT fk_organizacion_comentario FOREIGN KEY


(codigo_organizacion)

REFERENCES tb_organizacion (rif)

tb_comentario_servicio

Contiene los datos del comentario por servicio.

codigo_comentario character varying (5) NOT NULL,

codigo_servicio character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_comentario_servicio PRIMARY KEY (codigo),

CONSTRAINT fk_comentario_servicio FOREIGN KEY (codigo_comentario)

REFERENCES tb_comentario (codigo)

195
CONSTRAINT fk_servicio FOREIGN KEY (codigo_servicio)

REFERENCES tb_servicio (codigo)

tb_cubiculo

Contiene los datos del cubículo.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

status character varying (8),

CONSTRAINT id_cubiculo PRIMARY KEY (codigo)

tb_cubiculo_servicio

Contiene los datos del cubículo por servicio.

codigo character varying (5) NOT NULL,

codigo_maestro character varying (5),

codigo_servicio character varying (5),

status character varying (8),

CONSTRAINT id_cubiculo_servicio PRIMARY KEY (codigo),

CONSTRAINT fk_cubiculo_servicio FOREIGN KEY (codigo_maestro)

REFERENCES tb_cubiculo (codigo)

CONSTRAINT fk_servicio_cubiculo FOREIGN KEY (codigo_servicio)

REFERENCES tb_servicio (codigo)

tb_detalle_avance

Contiene los datos del detalle por avance.

codigo character varying (5) NOT NULL,

codigo_detalle_sesion character varying (5),

codigo_avance character varying (5),

numero_sesion integer,

196
fecha date,

valor character varying (30),

CONSTRAINT id_detalle_avance PRIMARY KEY (codigo),

CONSTRAINT fk_avance FOREIGN KEY (codigo_avance)

REFERENCES tb_avance (codigo)

CONSTRAINT fk_detalle_sesion FOREIGN KEY (codigo_detalle_sesion)

REFERENCES tb_detalle_sesion (codigo)

tb_detalle_paquete

Contiene los datos del detalle por paquete.

codigo_servicio character varying (5) NOT NULL,

codigo_paquete character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

cantidad_sesion integer,

CONSTRAINT id_detalle_paquete PRIMARY KEY (codigo),

CONSTRAINT fk_paquete_servicio FOREIGN KEY (codigo_paquete)

REFERENCES tb_paquete (codigo)

CONSTRAINT fk_servicio_paquete FOREIGN KEY (codigo_servicio)

REFERENCES tb_servicio (codigo)

tb_detalle_sesion

Contiene los datos del detalle por sesión.

codigo character varying (5) NOT NULL,

status character varying (8),

ejecucion_servicio boolean,

codigo_cita character varying(5),

197
codigo_notificacion character varying (5),

Numero_sesion integer,

CONSTRAINT id_detalle_sesion PRIMARY KEY (codigo),

CONSTRAINT fk_codigo_cita FOREIGN KEY (codigo_cita)

REFERENCES tb_cita (codigo)

CONSTRAINT fk_codigo_notificacion FOREIGN KEY (codigo_notificacion)

REFERENCES tb_notificacion (codigo)

tb_detalle_solicitud

Contiene los datos del detalle por solicitud.

codigo_solicitud character varying (5),

codigo_paquete character varying (5),

codigo_servicio character varying (5),

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_detalle_solicitud PRIMARY KEY (codigo),

CONSTRAINT fk_paquete_solicitud FOREIGN KEY (codigo_paquete)

REFERENCES tb_paquete (codigo)

CONSTRAINT fk_servicio_solicitud FOREIGN KEY (codigo_servicio)

REFERENCES tb_servicio (codigo)

CONSTRAINT fk_solicitud FOREIGN KEY (codigo_solicitud)

REFERENCES tb_solicitud (codigo)

198
tb_dia_laborable

Contiene los datos de los días laborables.

descripcion character varying (45),

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_dia_laborable PRIMARY KEY (codigo)

tb_diagnostico

Contiene los datos de la cita diagnóstico.

codigo character varying (5) NOT NULL,

codigo_cita character varying (5),

status character varying (8),

observacion character varying(500),

CONSTRAINT id_diagnostico PRIMARY KEY (codigo),

CONSTRAINT fk_cita_diagnostico FOREIGN KEY (codigo_cita)

REFERENCES tb_cita (codigo)

tb_disponibilidad_esteticista

Contiene los datos de la disponibilidad del esteticista.

codigo character varying (5) NOT NULL,

fecha date,

codigo_esteticista character varying (10),

status character varying (10),

codigo_bloque character varying (5),

CONSTRAINT id_disponibilidad_esteticista PRIMARY KEY (codigo),

CONSTRAINT fk_bloque_disponibilidad FOREIGN KEY (codigo_bloque)

REFERENCES tb_bloque (codigo)

199
CONSTRAINT fk_esteticista_disponibilidad FOREIGN KEY
(codigo_esteticista)

REFERENCES tb_esteticista (cedula)

tb_disponibilidad_cubiculo

Contiene los datos de la disponibilidad del cubículo.

codigo character varying(5) NOT NULL,

fecha date,

codigo_cubiculo character varying (5),

status character varying (10),

codigo_bloque character varying (5),

CONSTRAINT id_disponibilidad_cubiculo PRIMARY KEY (codigo),

CONSTRAINT fk_disponibilidad_bloque FOREIGN KEY (codigo_bloque)

REFERENCES tb_bloque (codigo)

CONSTRAINT fk_disponibilidad_cubiculo FOREIGN KEY (codigo_cubiculo)

REFERENCES tb_cubiculo (codigo)

tb_estado

Contiene los datos del estado.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

status character varying (8),

CONSTRAINT id_estado PRIMARY KEY (codigo)

tb_esteticista

Contiene los datos del esteticista.

200
cedula character varying (10) NOT NULL,

nombre character varying (20),

apellido character varying (20),

sexo character varying (9),

estado_civil character varying (10),

telefono character varying (12),

direccion character varying (100),

correo character varying (45),

codigo_estado character varying (5),

status character varying (8),

codigo_organizacion character varying (10),

fecha_nacimiento date,

CONSTRAINT id_esteticista PRIMARY KEY (cedula),

CONSTRAINT fk_estado_esteticista FOREIGN KEY (codigo_estado)

REFERENCES tb_estado (codigo)

CONSTRAINT fk_esteticista_usuario FOREIGN KEY (correo)

REFERENCES tb_usuario (usuario)

CONSTRAINT fk_organizacion_esteticista FOREIGN KEY (codigo_organizacion)

REFERENCES tb_organizacion (rif)

tb_formulario

Contiene los datos del formulario.

codigo_respuesta character varying (5) NOT NULL,

codigo_pregunta character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

201
status character varying (8),

tipo_encuesta character varying (5),

CONSTRAINT id_formulario PRIMARY KEY (codigo),

CONSTRAINT fk_pregunta_formulario FOREIGN KEY (codigo_pregunta)

REFERENCES tb_pregunta (codigo)

CONSTRAINT fk_respuesta_formulario FOREIGN KEY (codigo_respuesta)

REFERENCES tb_respuesta (codigo)

tb_formulario_cliente

Contiene los datos del formulario por cliente.

codigo character varying (5) NOT NULL,

codigo_cliente character varying (10),

codigo_formulario character varying(5),

status character varying (8),

CONSTRAINT id_formulario_cliente PRIMARY KEY (codigo),

CONSTRAINT fk_cliente_formulario FOREIGN KEY (codigo_cliente)

REFERENCES tb_cliente (cedula)

CONSTRAINT fk_formulario_cliente FOREIGN KEY (codigo_formulario)

REFERENCES tb_formulario (codigo)

tb_formulario__web_cliente

Contiene los datos del formulario por cliente en la web.

codigo_respuesta character varying (5),

codigo_cliente character varying (10),

codigo character varying (5) NOT NULL,

CONSTRAINT id_formulario_web_cliente PRIMARY KEY (codigo),

202
CONSTRAINT fk_codigo_cliente FOREIGN KEY (codigo_cliente)

REFERENCES tb_cliente (cedula)

CONSTRAINT fk_codigo_respuesta FOREIGN KEY (codigo_respuesta)

REFERENCES tb_respuesta (codigo)

tb_habito

Contiene los datos hábito.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

status character varying (8),

CONSTRAINT id_habito PRIMARY KEY (codigo)

tb_habito_cliente

Contiene los datos hábito por cliente.

codigo_habito character varying (5) NOT NULL,

codigo_cliente character varying (10) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_codigo_habito_cliente PRIMARY KEY (codigo),

CONSTRAINT fk_cliente_habito FOREIGN KEY (codigo_cliente)

REFERENCES tb_cliente (cedula)

CONSTRAINT fk_habito_cliente FOREIGN KEY (codigo_habito)

REFERENCES tb_habito (codigo)

203
tb_habito_servicio

Contiene los datos hábito por servicio.

codigo_maestro character varying (5) NOT NULL,

codigo_servicio character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_habito_servicio PRIMARY KEY (codigo),

CONSTRAINT fk_habito_servicio FOREIGN KEY (codigo_maestro)

REFERENCES tb_habito (codigo)

CONSTRAINT fk_servicio_habito FOREIGN KEY (codigo_servicio)

REFERENCES tb_servicio (codigo)

tb_horario

Contiene los datos del horario.

codigo_dia_laborable character varying (5) NOT NULL,

codigo_bloque character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_horario PRIMARY KEY (codigo),

CONSTRAINT fk_bloque FOREIGN KEY (codigo_bloque)

REFERENCES tb_bloque (codigo)

CONSTRAINT fk_dia_laborable FOREIGN KEY (codigo_dia_laborable)

REFERENCES tb_dia_laborable (codigo)

204
tb_horario_cubiculo

Contiene los datos del horario por cubículo.

codigo character varying (5) NOT NULL,

codigo_horario character varying (5),

codigo_cubiculo character varying (5),

status character varying (8),

codigo_agenda character varying (5),

CONSTRAINT id_horario_cubiculo PRIMARY KEY (codigo),

CONSTRAINT fk_cubiculo_horario FOREIGN KEY (codigo_cubiculo)

REFERENCES tb_cubiculo (codigo)

CONSTRAINT fk_horario_cubiculo FOREIGN KEY (codigo_horario)

REFERENCES tb_horario (codigo)

tb_horario_esteticista

Contiene los datos del horario por esteticista.

codigo_horario character varying (5) NOT NULL,

codigo_esteticista character varying (10) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

codigo_agenda character varying (5),

CONSTRAINT id_horario_esteticista PRIMARY KEY (codigo),

CONSTRAINT fk_codigo_agenda FOREIGN KEY (codigo_agenda)

REFERENCES tb_agenda (codigo)

CONSTRAINT fk_esteticista_horario FOREIGN KEY (codigo_esteticista)

REFERENCES tb_esteticista (cedula)

205
CONSTRAINT fk_horario_esteticista FOREIGN KEY (codigo_horario)

REFERENCES tb_horario (codigo)

tb_incidencia

Contiene los datos de las incidencias.

codigo character varying (5) NOT NULL,

descripcion character varying (130),

tipo_incidencia character varying (5),

status character varying (8),

CONSTRAINT id_incidencia PRIMARY KEY (codigo),

CONSTRAINT fk_tipo_incidencia FOREIGN KEY (tipo_incidencia)

REFERENCES tb_tipo_incidencia (codigo)

tb_incidencia_sesion

Contiene los datos de las incidencias por sesión.

codigo character varying (5) NOT NULL,

status character varying (8),

codigo_detalle_sesion character varying (5),

CONSTRAINT id_incidencia_sesion PRIMARY KEY (codigo),

CONSTRAINT fk_detalle_sesion FOREIGN KEY (codigo_detalle_sesion)

REFERENCES tb_detalle_sesion (codigo)

CONSTRAINT fk_incidencia_sesion FOREIGN KEY (codigo_incidencia)

REFERENCES tb_incidencia (codigo)

206
tb_indicador

Contiene los datos del indicador.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

status character varying (8),

CONSTRAINT id_indicador PRIMARY KEY (codigo)

tb_indicador_cliente

Contiene los datos del indicador por cliente.

codigo_indicador character varying (5),

codigo_cliente character varying (10),

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_indicador_cliente PRIMARY KEY (codigo),

CONSTRAINT fk_codigo_cliente FOREIGN KEY (codigo_cliente)

REFERENCES tb_cliente (cedula)

CONSTRAINT fk_codigo_indicador FOREIGN KEY (codigo_indicador)

REFERENCES tb_indicador (codigo)

tb_indicador_diagnostico

Contiene los datos del indicador por diagnóstico.

codigo_indicador character varying (5) NOT NULL,

codigo_diagnostico character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_indicador_diagnostico PRIMARY KEY (codigo),

CONSTRAINT fk_diagnostico_indicador FOREIGN KEY (codigo_diagnostico)

207
REFERENCES tb_diagnostico (codigo)

CONSTRAINT fk_indicador_diagnostico FOREIGN KEY (codigo_indicador)

REFERENCES tb_indicador (codigo)

tb_indicador_servicio

Contiene los datos del indicador por servicio.

codigo_maestro character varying (5) NOT NULL,

codigo_servicio character varying (5) NOT NULL,

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_indicador_servicio PRIMARY KEY (codigo),

CONSTRAINT fk_indicador_servicio FOREIGN KEY (codigo_maestro)

REFERENCES tb_indicador (codigo)

CONSTRAINT fk_servicio_indicador FOREIGN KEY (codigo_servicio)

REFERENCES tb_servicio (codigo)

tb_motivo_cancelacion

Contiene los datos del motivo de cancelación.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

status character varying (8),

CONSTRAINT id_motivo_cancelacion PRIMARY KEY (codigo)

tb_necesidad

Contiene los datos de la necesidad.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

208
status character varying (8),

CONSTRAINT id_necesidad PRIMARY KEY (codigo)

tb_necesidad_cliente

Contiene los datos de la necesidad por cliente.

codigo_cliente character varying (10) NOT NULL,

codigo character varying (5) NOT NULL,

codigo_necesidad character varying (5),

status character varying (8),

CONSTRAINT id_codigo_necesidad_cliente PRIMARY KEY (codigo),

CONSTRAINT fk_cliente_necesidad FOREIGN KEY (codigo_cliente)

REFERENCES tb_cliente (cedula)

tb_noticia

Contiene los datos de la noticia.

codigo character varying (5) NOT NULL,

status character varying (8),

codigo_sistema character varying (5),

fecha date,

tipo_noticia character varying (5),

titulo character varying (100),

contenido character varying(500),

imagen character varying,

CONSTRAINT id_noticia PRIMARY KEY (codigo),

CONSTRAINT fk_noticia_sistema FOREIGN KEY (codigo_sistema)

REFERENCES tb_sistema (codigo)

CONSTRAINT fk_tipo_noticia FOREIGN KEY (tipo_noticia)

209
REFERENCES tb_tipo_noticia (codigo)

tb_notificacion

Contiene los datos de las notificaciones.

codigo character varying (5) NOT NULL,

descripcion character varying (100),

status character varying (8),

titulo character varying (45),

tipo_notificacion character varying (5),

CONSTRAINT id_notificacion PRIMARY KEY (codigo),

CONSTRAINT fk_tipo_notificacion FOREIGN KEY (tipo_notificacion)

REFERENCES tb_tipo_notificacion (codigo)

tb_objetivo

Contiene los objetivos de la organizacion.

codigo character varying (5) NOT NULL,

descripcion character varying (500),

tipo_objetivo character varying (10),

codigo_organizacion character varying (10),

status character varying (8),

CONSTRAINT id_objetivo PRIMARY KEY (codigo),

CONSTRAINT fk_organizacion FOREIGN KEY (codigo_organizacion)

REFERENCES tb_organizacion (rif)

tb_ocupacion

Contiene la ocupación por cliente.

210
codigo character varying (5) NOT NULL,

descripcion character varying (45),

status character varying (8),

CONSTRAINT id_ocupacion PRIMARY KEY (codigo)

tb_ocupacion_servicio

Contiene la ocupación por servicio.

codigo_maestro character varying (5),

codigo_servicio character varying (5),

codigo character varying (5) NOT NULL,

status character varying (8),

CONSTRAINT id_ocupacion_servicio PRIMARY KEY (codigo),

CONSTRAINT fk_ocupacion FOREIGN KEY (codigo_maestro)

REFERENCES tb_ocupacion (codigo)

CONSTRAINT fk_servicio FOREIGN KEY (codigo_servicio)

REFERENCES tb_servicio (codigo)

tb_opcion

Contiene los datos de la opción.

codigo character varying (5) NOT NULL,

codigo_padre character varying (5),

vinculo character varying (100),

texto character varying (100),

status character varying (8),

icono character varying (50),

tabla character varying (25),

211
CONSTRAINT id_opcion PRIMARY KEY (codigo)

tb_opcion_rol

Contiene los datos de la opción por rol.

codigo character varying (5) NOT NULL,

codigo_opcion character varying (5),

status character varying (8),

codigo_rol character varying(5),

CONSTRAINT tb_opcion_rol_pkey PRIMARY KEY (codigo),

CONSTRAINT tb_opcion_rol_codigo_opcion_fkey FOREIGN KEY


(codigo_opcion)

REFERENCES tb_opcion (codigo)

CONSTRAINT tb_opcion_rol_codigo_rol_fkey FOREIGN KEY (codigo_rol)

REFERENCES tb_rol (codigo)

tb_organizacion

Contiene los datos de la organizacion.

rif character varying(10) NOT NULL,

nombre character varying (50),

tipo_organizacion character varying (5),

correo character varying (45),

direccion character varying (100),

telefono character varying(12),

mision character varying (500),

vision character varying (500),

status character varying(8),

212
hora_entrada timestamp with time zone,

hora_salida timestamp with time zone,

definicion character varying (500),

imagen character varying,

CONSTRAINT id_organizacion PRIMARY KEY (rif),

CONSTRAINT fk_tipo_organizacion FOREIGN KEY (tipo_organizacion)

REFERENCES tb_tipo_organizacion (codigo)

tb_paquete

Contiene los datos de los paquetes.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

tipo_paquete character varying (12),

status character varying (8),

imagen character varying,

precio double precision,

CONSTRAINT id_paquete PRIMARY KEY (codigo)

tb_perfil_usuario

Contiene los datos del perfil del usuario.

cedula character varying (10) NOT NULL,

nombre character varying (20),

apellido character varying (20),

sexo character varying (9),

estado_civil character varying(10),

telefono character varying(12),

213
direccion character varying (100),

correo character varying (45),

codigo_estado character varying (5),

status character varying (8),

codigo_organizacion character varying (10),

fecha_nacimiento date,

CONSTRAINT id_perfil_usuario PRIMARY KEY (cedula),

CONSTRAINT fk_estado_perfil FOREIGN KEY (codigo_estado)

REFERENCES tb_estado (codigo)

CONSTRAINT fk_organizacion FOREIGN KEY (codigo_organizacion)

REFERENCES tb_organizacion (rif)

CONSTRAINT fk_perfil_usuario FOREIGN KEY (correo)

REFERENCES tb_usuario (usuario)

tb_preferencia

Contiene los datos de la preferencia.

codigo character varying (5) NOT NULL,

descripcion character varying (45),

status character varying (8),

tipo_preferencia character varying,

imagen character varying,

CONSTRAINT id_preferencia PRIMARY KEY (codigo),

CONSTRAINT fk_tipo_preferencia FOREIGN KEY (tipo_preferencia)

REFERENCES tb_tipo_preferencia (codigo)

214
215
216
217
218
219
CAPITULO VII
EQUIPO DESARROLLADOR

220
Descripción del Capitulo

En el siguiente capítulo, se detallará el equipo desarrollador del Sistema de


Información Bambú, junto con la fotografía de sus integrantes.

Logo del Equipo Desarrollador

Figura 123.Logo del Equipo Desarrollador.

Logo del Sistema

221
Figura 124.Logo del Sistema.

Foto del Equipo

Figura 125.Foto del Equipo Desarrollador.

222
Lista de Integrantes del Equipo

Nro. Apellidos Nombres

1 Castillo Álvarez Johanner Jizel

2 Castillo Guilfrida Richard Josue

3 Chaer Chaer Jalid

4 Chang Rodríguez Ligia Andreina

5 Colina Quintero Gerardo Javier

6 Contento Simancas Carlos Manuel

7 Franceschini Maldonado Bertino

8 Kahwati Aguilar Jesus Eduardo

9 León Freites Yhosemar Alejandra

10 Lozano Roque Ericker Alexander

11 Oropeza Brito Génesis Dubraska

12 Ortega Castillo Diannyz Elena

13 Pérez Goyo Glennys Yunancys

14 Rodríguez Quijada Yender Jesús

15 Suarez Méndez Tomas Enrique

16 Tabares Rivero Andrés Gerardo

17 Torres Gamarra Glani Maria

223
224

S-ar putea să vă placă și