UNIVERSIDAD NACIONAL JORGE BASADRE GROHMANN

FACULTAD DE INGENIERA
ESCUELA ACADMICO PROFESIONAL DE
INGENIERA EN INFORMTICA Y SISTEMAS

1Sistema Web Centro Odontolgico Promident

Henrry Cachicatari &Yuly Choque & Jesus Qquehue & Kevin Flores & Luis
Castillo
Mayo 2016
Universidad Nacional Jorge Basadre Grohmann
Escuela Profesional de Ingeniera en Informtica y Sistemas
Sistemas de Informacin II

Copyright 2016 por Henrry Cachicatari &Yuly Choque & Jesus Qquehue & Kevin
Flores & Luis Castillo. Todos los derechos reservados.

Dedicatoria
Dedicamos este trabajo a nuestros padres que estn siempre motivndonos a ser mejores
personas y a nuestros profesores porque nos ensean a ser mejores profesionales.

Tabla de Contenidos
INTRODUCIN..............................................................................................................................1
Captulo 1 Introduccin e informacin general...............................................................................2
Anlisis de la Organizacin.........................................................................................................2
Datos generales de la organizacin..........................................................................................2
Razon social.........................................................................................................................2
Descripcin..........................................................................................................................2
Ubicacin.............................................................................................................................2
Descripcin de la problemtica...............................................................................................4
Resultados esperados...............................................................................................................4
Captulo 2 Fundamento terico......................................................................................................6
Sistema y software.......................................................................................................................6
Sistema.....................................................................................................................................6
Software...................................................................................................................................6
Anlisis de sistemas.....................................................................................................................6
Diseo de sistemas.......................................................................................................................7
Base de datos...............................................................................................................................7
Metodologa.................................................................................................................................7
Metodologa scrum......................................................................................................................8
Fases que definen el ciclo de desarrollo gil.........................................................................10
Concepto............................................................................................................................10
Especulacin......................................................................................................................10
Exploracin........................................................................................................................10
Revisin.............................................................................................................................11
Cierre.................................................................................................................................11
Componentes de Scrum.........................................................................................................12
Las reuniones.....................................................................................................................12
Los roles.............................................................................................................................13
Elementos de Scrum..........................................................................................................14
Desarrollo de las fases de un proyecto en Scrum..............................................................20
Arquitectura de Software...........................................................................................................23
Base de datos relacional.............................................................................................................23
Trello..........................................................................................................................................24
Captulo 3 Desarrollo y propuestas...............................................................................................26
Material utilizado.......................................................................................................................26
Hardware................................................................................................................................26
Software.................................................................................................................................27
Metodologa...............................................................................................................................28
Detalle de la metodologa......................................................................................................28
Captulo 4 Desarrollo del proyecto...............................................................................................29
Recursos humanos.....................................................................................................................29
Calendarizacin del proyecto....................................................................................................31
Producto Backlog.......................................................................................................................32
Reuniones..................................................................................................................................35

Validacin de diagramas de casos de Uso.................................................................................36

Descripcin de los diagramas de casos de uso......................................................................37
Registrar paciente..............................................................................................................37
Agendar cita.......................................................................................................................37
Buscar Cita Previa.............................................................................................................38
Programar cita....................................................................................................................39
Consulta mdica.................................................................................................................39
Realizar Tratamiento..........................................................................................................40
Historial Clnico.................................................................................................................42
Odontograma.....................................................................................................................42
Base de datos del sistema: Diagrama entidad-relacin..............................................................43
Descripcin de las entidades del diagrama entidad-relacin.................................................44
Entidad Persona:................................................................................................................44
Entidad Odontlogo:..........................................................................................................44
Entidad Historia Clnica:...................................................................................................45
Entidad Tratamiento:.........................................................................................................45
Entidad Pieza:....................................................................................................................46
Entidad diente_div:............................................................................................................47
Descripcin de las relaciones en el diagrama entidad-relacin:............................................47
Relacin Atiende................................................................................................................47
Relacin Posee (Persona Historia Clnica):....................................................................48
Relacin Posee (Historia Clnica Tratamiento):.............................................................49
Relacin Aplica:.................................................................................................................49
Relacin Posee (Pieza Diente_div):................................................................................50
Diagrama del modelo relacional............................................................................................51
Tabla est_civil....................................................................................................................52
Tabla Persona.....................................................................................................................53
Tabla odontlogo...............................................................................................................54
Tabla Antecedente:.............................................................................................................54
Tabla Citas.........................................................................................................................55
Tabla Historia Clnica........................................................................................................56
Tabla Tratamiento..............................................................................................................57
Tabla Pieza:........................................................................................................................58
Tabla Diente_div:...............................................................................................................58
Interfaces 2.0 promidentodontology......................................................................................58
Login:.................................................................................................................................58
Olvid mi contrasea.........................................................................................................59
Mensaje a tu Correo Electrnico.......................................................................................60
Cambio de contrasea........................................................................................................61
Men Principal...................................................................................................................62
Seccin Dentista................................................................................................................63

INDICE DE TABLAS
Tabla 1: Descripcin el software utilizado para el desarrollo........................................................27
Tabla 2: Distribucin del equipo de desarrollo..............................................................................29
Tabla 3: CUS registrar paciente.....................................................................................................37
Tabla 4: CUS Agendar Cita...........................................................................................................37
Tabla 5: CUS Buscar cita previa....................................................................................................38
Tabla 6: CUS Programar citas.......................................................................................................39
Tabla 7: CUS consulta mdica.......................................................................................................40
Tabla 8: CUS Realizar Tratamiento...............................................................................................41
Tabla 9: CUS Historial Clnico......................................................................................................42
Tabla 10: CUS Odontograma.........................................................................................................43

Lista de figuras
Figura 1: Ubicacin del Centro Odontolgico PROMIDEN local central...............................3
Figura 2: Ubicacin del Centro Odontolgico PROMIDEN sucursal......................................4
Figura 3: Ciclo de desarrollo gil...................................................................................................11
Figura 4: Ciclo principal de scrum................................................................................................12
Figura 5: Ejemplo de historia de usuario.......................................................................................17
Figura 6: Ejemplo de Product Backlog..........................................................................................18
Figura 7: Ejemplo de Sprint Backlog............................................................................................19
Figura 8: Calendarizacin del Proyecto.........................................................................................31
Figura 9: Muestra de diagrama......................................................................................................32
Figura 10: Los requerimientos.......................................................................................................33
Figura 11: Tareas que se planearon hacer primero........................................................................34
Figura 12: tareas que se estn haciendo y las que ya se hicieron primera semana........................34
Figura 13: avance de la segunda semana.......................................................................................35
Figura 14: Avance segn calendarizacin......................................................................................35
Figura 15: CUS general del Sistema..............................................................................................36
Figura 16: Descripcin de la entidad persona................................................................................44
Figura 17: Descripcin de la entidad Odontlogo.........................................................................45
Figura 18: descripcin de entidad clnica.....................................................................................45
Figura 19: Descripcin de TRatameinto........................................................................................46
Figura 20: Descripcin Pieza.........................................................................................................46
Figura 21: Descripcin del diagram diente div..............................................................................47
Figura 22: Descripcin E-R atiende..............................................................................................47
Figura 23: descripcin de la Relacin Posee (Persona Historia Clnica)...................................48
Figura 24: Descripcin de la Relacin Posee (Historia Clnica Tratamiento)............................49
Figura 25: Descripcin de la relacin Aplica................................................................................49
Figura 26: Descripcin de la Relacin Posee (Pieza Diente_div)..............................................50
Figura 27: Diagrama del modelo relacional..................................................................................51
Figura 28: Login de Sistema Odontolgico Promident.................................................................59
Figura 29: Interfaz de recuperar contrasea mediante correo electrnico.....................................60
Figura 30: Mensaje de cambio de contrasea................................................................................60
Figura 31: Interfaz de cambio de contrasea.................................................................................61
Figura 32: Listado de dentistas......................................................................................................63
Figura 33: Interfaz registrar dentista..............................................................................................64

INTRODUCIN
Los sistemas de informacin en la realidad estn cambiando la forma de trabajar,
en casi la mayora de las empresas a nivel mundial y usan software a medida para
automatizar y mejorar los procesos administrativos, los cuales se aplican a diferentes
reas.
Los sistemas de informacin en la realidad tienen un papel fundamental, ya que
estos permiten gestionar diversas funciones dentro de una empresa o institucin debido a
la gran demanda que tienen para as mejorar en los puntos ms vulnerables de la empresa.
El presente informe se realiz con la finalidad de dar a conocer las actividades
(gestin de historial y citas de los pacientes) que realiza la empresa en mencin.

Captulo 1
Introduccin e informacin general

Anlisis de la Organizacin
Datos generales de la organizacin

Razon social

Centro odontolgico PROMIDENT

Descripcin

Centro Odontolgico PROMIDENT es un equipo de dentistas especializados

capacitados que utilizamos tcnicas, materiales y equipos de tecnologa de vanguardia.
Cuidamos en todo momento la esttica y la funcin que son de vital importancia para
lograr tratamientos exitosos con calidad y durabilidad para cada uno de nuestros
pacientes.

Ubicacin

El local del Centro Odontolgico PROMIDENT queda en la Calle Bilivar

N607 of. 102 (Esquina Pasaje Libertar con Bolivar) - Tacna. Tambin cuenta con una
sucursal en la As. Los Claveles Mz-46 Lt-03 Av. Los escritores (Frente del Mercado
Santa Rosa y al costado de la financiera Credinka) - Distrito Gregorio Albarracn
Lanchipa.

 Ubicacin Geogrfica
Local principal

Distrito: Tacna

Provincia: Tacna

Regin: Tacna

Figura 1: Ubicacin del Centro Odontolgico PROMIDEN local central

Sucursal

Distrito: Gregorio Albarracn Lanchipa

Provincia: Tacna

Regin: Tacna

Figura 2: Ubicacin del Centro Odontolgico PROMIDEN sucursal

Descripcin de la problemtica
En la clnica odontolgica PROMIDENT se ha podido observar que tienen
problemas con la gestin de citas a los pacientes ya que actualmente se realiza de forma
manual, lo que no permite una buena organizacin de la Doctora, y aunque tambin
registra las citas en su agenda de celular, aun as ya muchas veces se ha olvidado de
alguna cita. Adems se ha comprobado que las historias clnicas tambin se registran
manualmente y por lo que se ha visto lo almacenan en archivadores lo que ocasiona la
demora al buscar la historia de un paciente para poder observar que tratamiento est
siguiendo o anotar incidencias.
Resultados esperados
Se desea como resultado obtener un software didctico y manejable para reducir
tiempo y tener un mayor control de diagnsticos para los pacientes; reducir gastos
operativos innecesarios y mejorar el proceso de gestin de historias clnicas, ya que este

proceso es muy importante para la empresa y los pacientes, debido a que en ella se recoge
informacin para la correcta atencin de los pacientes.

Captulo 2
Fundamento terico
Sistema y software
Sistema
Es un grupo de partes y objetos que interaccionan, y que toman un todo o que se
encuentran bajo la influencia de fuerzas en alguna relacin definida.
Software
Pressman define Software como: Son programas de computadora, estructura de
datos y su documentacin que sirven para hacer efectivo el mtodo lgico, procedimiento
o control requerido.
Software se refiere al equipamiento o soporte lgico de una computadora digital,
y comprende el conjunto de los componentes lgicos necesarios para hacer posible la
realizacin de tareas especficas; en contraposicin a los componentes fsicos del sistema,
llamados hardware. Tales componentes lgicos, incluyen entre muchos otros,
aplicaciones informticas como procesador de textos, hojas de clculo, control de
inventarios, registros de compras y ventas, etc.
Ahora, conociendo las definiciones de sistema y software, se puede decir que un
software es un sistema, ya que est compuesto por clases abstradas de la realidad que
interaccionan entre s para realizar procesos definidos por su programador con un fin
especfico para el usuario final.
Anlisis de sistemas
Es el proceso de clasificacin e interpretacin de hechos. Diagnsticos de

problemas y empleo de la informacin para recomendar mejoras al sistema. Este es el

trabajo del analista de sistemas.
Diseo de sistemas
Es el proceso de planificar, reemplazar o complementar un sistema organizacional
existente. Pero antes de llevar a cabo esta planeacin es necesario comprender, en su
totalidad, el viejo sistema y determinar la mejor forma en que se pueden, si es posible,
utilizar las computadoras para hacer la operacin ms eficiente.
Base de datos
C. J. Date define Base de Datos como: Un sistema computarizado para llevar
registros. Es posible considerar a la propia base de datos como una especie de armario
electrnico para archivar, es decir, es un depsito o contenedor de una coleccin de
archivos de datos computarizados.
Los usuarios del sistema pueden realizar una variedad de operaciones sobre
dichos archivos; por ejemplo:

Agregar nuevos archivos vacos a la base de datos.

Insertar datos dentro de los archivos existentes.
Recuperar datos de los archivos existentes.
Modificar datos en archivos existentes.
Eliminar datos de los archivos existentes.
Eliminar archivos existentes de la base de datos.

Metodologa
Bernd Bruegge y Allen H. Dutoit define Metodologa como: Una coleccin de mtodos
para la resolucin de una clase de problemas. Las metodologas de desarrollo de
software descomponen el proceso en actividades: Anlisis, diseo e implementacin.

Mtodo es el camino para llegar a su fin, el modo de obrar y de proceder para alcanzar un
objetivo determinado.
Metodologa scrum
En el ao 1986 Takeuchi y Nonaka publicaron el artculo The New Product
Developroent Game el cual dar a conocer una nueva forma de gestionar proyectos en la
que la agilidad, flexibilidad, y la incertidumbre son los elementos principales.
Nonaka y Takeuchi se fijaron en empresas tecnolgicas que, estando en el mismo
entorno en el que se encontraban otras empresas, realizaban productos en menos tiempo,
de buena calidad y menos costes.
Observando a empresas como Honda, HP, Canonetc., se dieron cuenta de que el
producto no segua unas fases en las que haba un equipo especializado en cada una de
ellas, si no que se parta de unos requisitos muy generales y el producto lo realizaba un
equipo multidisciplinar que trabajaba desde el comienzo del proyecto hasta el final.
Se compar esta forma de trabajo en equipo, con la colaboracin que hacen los
jugadores de Rugby y la utilizacin de una formacin denominada SCRUM.
Scrum aparece como una prctica destinada a los productos tecnolgicos y ser en
1993 cuando realmente Jeff Sutherland aplique un modelo de desarrollo de Software en
Ease/Corporation.

En 1996, Jeff Sutherland y Ken Schwaber presentaron las prcticas que se usaban
como proceso formal para el desarrollo de software y que pasaran a incluirse en la lista
de Agile Alliance.

Scrum es adecuado para aquellas empresas en las que el desarrollo de los

productos se realiza en entornos que se caracterizan por tener:
A) Incertidumbre
Sobre esta variable se plantea el objetivo que se quiere alcanzar sin proporcionar
un plan detallado del producto.
Esto genera un reto y da una autonoma que sirve para generar una tensin
adecuada para la motivacin de los equipos.
B) Auto organizacin
Los equipos son capaces de organizarse por s solos, no necesitan roles para la
gestin, pero tienen que reunir las siguientes caractersticas:

Autonoma: Son los encargados de encontrar la solucin usando la estrategia que

encuentren adecuada.
Autosuperacin: Las soluciones iniciales sufrirn mejoras.
Auto-enriquecimiento: Al ser equipos multidisciplinares se ven enriquecidos de
forma mutua, aportando soluciones que puedan complementarse.

C) Control moderado
Se establecer un control suficiente para evitar descontroles. Se basa en crear un
escenario de autocontrol entre iguales para no impedir la creatividad y
espontaneidad de los miembros del equipo.
D) Transmisin del conocimiento
Todo el mundo aprende de todo el mundo. Las personas pasan de unos proyectos
a otros y as comparten sus conocimientos a lo largo de la organizacin.
Fases que definen el ciclo de desarrollo gil

Concepto
Se define de forma general las caractersticas del producto y se asigna el equipo
que se encargar de su desarrollo.

Especulacin
En esta fase se hacen disposiciones con la informacin obtenida y se establecen
los lmites que marcarn el desarrollo del producto, tales como costes y agendas.
Se construir el producto a partir de las ideas principales y se comprueban las
partes realizadas y su impacto en el entorno. Esta fase se repite en cada iteracin y
consiste, en rasgos generales, en:

Desarrollar y revisar los requisitos generales.

Mantener la lista de las funcionalidades que se esperan.
Plan de entrega. Se establecen las fechas de las versiones, hitos e iteraciones.
Medir el esfuerzo realizado en el proyecto.

Exploracin
Se incrementa el producto en el que se aaden las funcionalidades de la fase de
especulacin.

Revisin
El equipo revisa todo lo que se ha construido y se contrasta con el objetivo
deseado.

Cierre
Se entregar en la fecha acordada una versin del producto deseado. Al

tratarse de una versin, el cierre no indica que se ha finalizada el proyecto, sino que
seguir habiendo cambios, denominados mantenimiento, que har que el producto final
se acerque al producto final deseado.

Figura 3: Ciclo de desarrollo gil

Scrum gestiona estas iteraciones a travs de reuniones diarias, uno de los

elementos fundamentales de esta metodologa.

Figura 4: Ciclo principal de scrum

Componentes de Scrum

Las reuniones

Planificacin de Backlog
Se definir un documento en el que se reflejarn los requisitos del sistema por
prioridades.
En esta fase se definir tambin la planificacin del Sprint 0, en la que se decidir
cules van a ser los objetivos y el trabajo que hay que realizar para esa iteracin.
Se obtendr adems en esta reunin un Sprint Backlog, que es la lista de tareas y

que es el objetivo ms importante del Sprint.

Seguimiento del Sprint
En esta fase se hacen reuniones diarias en las que las 3 preguntas principales para
evaluar el avance de las tareas sern:
Qu trabajo se realiz desde la reunin anterior?
Qu trabajo se har hasta una nueva reunin?
Inconvenientes que han surgido y qu hay que solucionar para poder continuar.

Revisin del Sprint

Cuando se finaliza el Sprint se realizar una revisin del incremento que se ha
generado. Se presentarn los resultados finales y una demo o versin, esto ayudar a
mejorar el feedback con el cliente.

Los roles

Los cerdos
Son las personas que estn comprometidas con el proyecto y el proceso de Scrum.

Product Owner: Es la persona que toma las decisiones, y es la que realmente

conoce el negocio del cliente y su visin del producto. Se encarga de escribir las
ideas del cliente, las ordena por prioridad y las coloca en el Product Backlog.
ScrumMaster: Es el encargado de comprobar que el modelo y la metodologa

funciona. Eliminar todos los inconvenientes que hagan que el proceso no fluya

e interactuar con el cliente y con los gestores.

Equipo De Desarrollo: suele ser un equipo pequeo de unas 5-9 personas y
tienen autoridad para organizar y tomar decisiones para conseguir su objetivo.
Est involucrado en la estimacin del esfuerzo de las tareas del Backlog.

Las gallinas
Aunque no son parte del proceso de Scrum, es necesario que parte de la
retroalimentacin de la salida del proceso y as poder revisar y planear cada

sprint.

Usuarios: Es el destinatario final del producto.

Stakeholders: Las personas a las que el proyecto les producir un beneficio.

Participan durante las revisiones del Sprint.

Managers: Toma las decisiones finales participando en la seleccin de los
objetivos y de los requisitos.

Elementos de Scrum

Product Backlog
Es el inventario en el que se almacenan todas las funcionalidades o requisitos en
forma de lista priorizada. Estos requisitos sern los que tendr el producto o los que
ir adquiriendo en sucesivas iteraciones.
La lista ser gestionada y creada por el cliente con la ayuda del Scrum Master,
quien indicar el coste estimado para completar un requisito, y adems contendr
todo lo que aporte un valor final al producto. Las cuatro caractersticas principales de
esta lista de objetivos sern:

Contendr los objetivos del producto, se suele usar para expresarlos las historias

de usuario.
En cada objetivo, se indicar el valor que le da el cliente y el coste estimado; de
esta manera, se realiza la lista, priorizando por valor y coste, se basar en el

ROI.
En la lista se tendrn que indicar las posibles iteraciones y los releases que se

han indicado al cliente.

La lista ha de incluir los posibles riesgos e incluir las tareas necesarias para
solventarlos.
Es necesario que antes de empezar el primer Sprint se definan cules van a ser los

objetivos del producto y tener la lista de los requisitos ya definida. No es necesario

que sea muy detallada, simplemente deber contener los requisitos principales para
que el equipo pueda trabajar. Realizar este orden de tareas tiene como beneficios:

El proyecto no se paraliza simplemente por no tener claro los requisitos menos

relevantes, y el cliente podr ver resultados de forma ms rpida.

Los requisitos secundarios aparecern a medida que se va desarrollando el

proyecto, por lo tanto, no se pierde tanto tiempo en analizarlos al principio y el

cliente ser ms consciente de sus necesidades.
Los requisitos secundarios puede que no se lleguen a necesitar porque se han

sustituido o porque no reportan un retorno ROI interesante.

Una vez definidos los requisitos se tendr que acordar cundo se tiene que
entender un objetivo como terminado o completado. Se entiende que un producto
est completado si:

Asegura que se puede realizar un entregable para realizar una demostracin de

los requisitos y ver qu se han cumplido.

Incluir todo lo necesario para indicar que se est realizando el producto que el
cliente desea.
Como complemento a la definicin de completado, se debera de asociar una

condicin de aceptacin o no aceptacin a cada objetivo en el mismo momento en el

que se crea la lista.
Finalmente el Product Backlog ir evolucionando mientras el producto exista en
el mercado. Esta es la forma para evolucionar y tener un valor de producto para el
cliente suficiente para ser competitivo.
o Las historias de Usuario
Son las descripciones de las funcionalidades que va a tener el software.
Estas historias de usuario, sern el resultado de la colaboracin entre el cliente y
el equipo, e irn evolucionando durante toda la vida del proyecto. Las historias
de usuario se componen de tres fases denominadas Las 3 C:

Card: Ser una breve descripcin escrita que servir como recordatorio.
Conversation: Es una conversacin que servir para asegurarse de que se

ha entendido bien todo, y concretar el objetivo.

Confirmation: Tests funcionales para fijar detalles que sean relevantes e

indicar cul va a ser el lmite.

Figura 5: Ejemplo de historia de usuario

ID: Identificador de la historia de usuario.

TTULO: Ttulo descriptivo de la historia de usuario.
DESCRIPCIN: Descripcin sintetizada de la historia de usuario.
ESTIMACIN: Evaluacin del coste de implementacin en unidades de
desarrollo.

Estas

unidades

representarn

el

tiempo

terico

(desarrollo/hombre) que se haya estimado al comienzo del proyecto.

PRIORIDAD: Prioridad en la implementacin de la historia de usuario
respecto al resto de las historias de usuario. A mayor nmero, mayor
prioridad. Otra aproximacin a la priorizacin de tareas se hace a travs

del mtodo MoSCoW:

M Must, se debe completar este requerimiento para finalizar el proyecto.
S Should, se debe completar este proyecto por todos los medios, pero el

xito del proyecto no depende de l.

C Could, se debera completar este requerimiento si su implementacin

no afecta a la consecucin de los objetivos principales del proyecto.

W Would, se puede completar este requerimiento si sobra tiempo de

desarrollo (o en futuras versiones del mismo)

DEPENDENCIAS: Una historia de usuario no debera ser dependiente de
otra historia, pero a veces es inevitable. En este apartado se indicaran los

IDs de las tareas de las que depende una tarea.

o Formato de Pila del Producto
En Scrum, la preferencia por tener documentacin en todo momento es
menos estricta. Se encuentra ms necesario el mantener una comunicacin
directa con el equipo, por eso se usa como herramienta el Backlog.
Aunque no hay ningn producto especial a la hora de confeccionar la lista,
es conveniente que incluya informacin relativa a:

Identificador para la funcionalidad.

Descripcin de la funcionalidad.
Sistema de priorizacin u orden.
Estimacin.

Figura 6: Ejemplo de Product Backlog

Sprint Backlog
Es la lista de tareas que elabora el equipo durante la planificacin de un Sprint.
Se asignan las tareas a cada persona y el tiempo que queda para terminarlas.
De esta manera el proyecto se descompone en unidades ms pequeas y se puede
determinar o ver en qu tareas no se est avanzando e intentar eliminar el problema.

Figura 7: Ejemplo de Sprint Backlog

La lista funciona de la siguiente manera:
Es una lista ordenada por prioridades para el cliente.
Puede haber dependencias entre una tarea y otra, por lo tanto se tendr que
diferenciar de alguna manera.
Todas las tareas tienen que tener un coste semejante que ser entre 4-16 horas.
El formato de la lista se presenta:
Hojas de clculo.
Pizarras.
Herramientas colaborativas.
Generalmente, las tareas a completar se suelen gestionar mediante el Scrum
Taskboard, a cada objetivo se le asignan las tareas necesarias para llevarlo a cabo, se
usan post-its que se van moviendo de una columna a otra para cambiar el estado.
Se debe incluir:
Lista de tareas.
Persona responsable de cada tarea, el estado en el que se encuentra y el tiempo
que queda por terminarla.
Permite la consulta diaria del equipo.
Permite tener una referencia diaria del tiempo que le queda a cada tarea.

Incremento

Representa los requisitos que se han completado en una iteracin y que son
perfectamente operativos.
Segn los resultados que se obtengan, el cliente puede ir haciendo los cambios
necesarios y replanteando el proyecto.

Desarrollo de las fases de un proyecto en Scrum

Preparacin del proyecto

Conocida como Sprint 0, es la fase inicial en la que se intenta comprender el caso
de negocio con la finalidad de tomar decisiones que agreguen valor al producto.
Durante esta fase se producen gran nmero de inexactitudes con las estimaciones,
pero es lgico, debido a que se hacen a alto nivel, por lo tanto es aconsejable no
perder tiempo en buscar las estimaciones exactas, es mejor invertir ese tiempo en el
desarrollo del producto. De esta manera el Backlog del producto usar como unidad
de tiempo das.
Las tareas a realizar en el sprint 0 son:
Definir el proyecto: Se debera de indicar de forma clara el propsito del
proyecto, no es necesario entrar en detalle pero s que todo el equipo sea capaz de
entender cules son las necesidades del producto y del cliente.
Definir terminado: Marcar el punto en el que se va a considerar que la tarea
est terminada.
Definicin del Backlog inicial: Se comienza la creacin del Backlog del producto
para que el Sprint siguiente contenga elementos de la lista suficientes para
comenzar a trabajar. Esta lista de elementos ser marcada por el Product Owner,
que tendr como responsabilidad priorizar las funcionalidades que, al
desarrollarlas e implementarlas cumplan las especificaciones consiguiendo
adems que su beneficio supere a su coste.
Definicin de los entregables: Una vez que se tiene el Backlog con las
funcionalidades, es necesario establecer criterios para hacer pequeas entregas

entregables del producto y as obtener su valor y un feedback temprano.

El plan de entregables puede sufrir modificaciones, muchas de ellas propiciadas
por:
Cambia el entorno y aparecen nuevas oportunidades para el negocio.
Se encuentran nuevas funcionalidades y estas proporcionan un valor si se pusiese
en produccin.
Replanteamiento del entregable.
El plan de entregas lo determinar el negocio, que ser el encargado de marcar
qu funciones, calidad y coste va a tener.
De la misma manera, estar sujeto a unas determinadas condiciones determinadas
por el equipo de trabajo que sern:
Tiempo para un entregable.
La estimacin inicial.
Seleccin del Backlog del producto.
Se hace una reunin inicial con todos los roles del equipo para tratar:
Dimensin del proyecto.
Revisiones del Backlog.
Organizacin del equipo y horario para establecer reuniones de control.

Planificar un Sprint
Denominado tambin Sprint Planning Meeting, tiene como finalidad realizar
una reunin, en la que participarn el Product Owner, el Scrum Master y el
equipo, con la intencin de seleccionar de la lista Backlog del producto las
funcionalidades sobre las que se va a trabajar, y que darn valor al producto.
Antes de comenzar la reunin el Product Owner tendr que preparar el
Backlog. La reunin se realiza en con time-box de ocho horas que se divide en 2
partes de 4 horas.

El desarrollo del Sprint

En los Sprints, el equipo trabaja para conseguir un incremento del producto, que

ser productivo para el Producto Owner y los Stakeholders.

El tiempo ms conveniente est entre 2 y 4 semanas, o 30 das
consecutivos como mximo. Estos intervalos de tiempo, son los que se consideran
ms apropiados para que el Stakeholders no pierda el inters.
Arquitectura de Software
Arquitectura de Software, es el diseo de ms alto nivel de la estructura de un
sistema informtico. Una arquitectura de software consiste en un conjunto de patrones y
abstraccione scoherentes que proporcionan el marco de referencia necesario para guiar la
construccin del software de un sistema de informacin. La arquitectura de software debe
establecer los fundamentos para que analistas, diseadores, programadores, testeadores y
todos los recursos humanos de un proyecto trabajen en una lnea comn que permita
alcanzar los objetivos del sistema de informacin, cubriendo todas las necesidades. Toda
arquitectura debe ser implementable en una arquitectura fsica para determinar qu
computadora ejecutar una tarea.
Base de datos relacional
Segn Elmari y Navarthe, una base de datos es un conjunto de datos relacionados
entre s y tiene las siguientes caractersticas:

Una base de datos representa algn aspecto del mundo real, en ocasiones llamado
mini mundo o universo de discurso. Las modificaciones del mini mundo se
reflejan en la base de datos.

Una base de datos es un conjunto de datos lgicamente coherente, con cierto

significado inherente. Una coleccin de datos aleatorios no pueden considerarse
propiamente una base de datos.

Toda base de datos se disea, construye y puebla con datos para un propsito

especfico. Est dirigido a un grupo de usuarios y tiene ciertas aplicaciones

preconcebidas que interesan a dichos usuarios.
Base de Datos Relacional es una coleccin de datos interrelacionados,
almacenados en conjunto sin redundancias perjudiciales o innecesarias; cuya finalidad es
servir a una o ms aplicaciones de la mejor forma posible; los datos se almacenan de
modo que resulten independientes de los programas que lo usan; se emplean mtodos
bien determinados para incluir nuevos datos y para modificar o extraer los datos
almacenados.
Las principales caractersticas de una base de datos relacional son: Su
composicin por varias tablas y relaciones (cada tabla, representa a una entidad del
sistema, del cual se almacena informacin), la no existencia de dos tablas con el mismo
nombre; y cada tabla es un conjunto de registros en filas o columnas.
Para acceder o modificar una base de datos relacional, es necesario conocer
primero lgebra relacional para poder utilizar lenguajes de consulta como el Structure
Query Language (SQL).
Trello
Trello es una herramienta de gestin de proyectos que hace que la colaboracin
sea sencilla

e incluso divertida. La realidad es que sirve para casi todo, ya ests

organizando proyecto en el trabajo, tareas del hogas, viajes o cualquier otra cosa.
Un board de Trello es bsicamente una pgina web que contiene listas dispuestas
de manera horizontal de modo que puedas apreciar, de una vistazo, todo lo que hay en tu
proyecto. Los tems dentro de las listas, llamados cards, pueden arrastrarse y soltarse en
otras listas y reordenarse.

Las cards individuales pueden contener listas de tareas, imgenes, archivos

adjuntos, fechas de entrega, etiquetas de colores y comentarios de otras personas que
compartan contigo el board. Puedes tener tanto boards como quieras, utilizar una para
Tareas del Hogar, por ejemplo, y otra para Planes de dominacin mundial.

Captulo 3
Desarrollo y propuestas
Material utilizado
El material utilizado se clasifica directamente en dos tipos: Hardware y Software.
Hardware
A continuacin se listarn las caractersticas de los diferentes computadoras personales
usados para el desarrollo de este proyecto.
Laptop TOSHIBA Satellite P55-B

Procesador: Intel Core i7

Memoria RAM: 12.0 GB

Disco duro: 1 TB

Laptop/Computadora 20296

Procesador: Intel Core i5

Memoria RAM: 6 GB

Disco duro: 1 TB

Laptop WBIBX-10J

Procesador: Intel Core i5

Memoria RAM: 4 GB

Disco duro: 500 GB

Laptop ASUS S46CB-WX155H

Procesador: Intel Core i5

Memoria RAM: 6 GB

Disco duro: 700 GB

Laptop Z480

Procesador: Intel Core i5

Memoria RAM: 6 GB

Disco duro: 700 GB

Software

Tabla 1: Descripcin el software utilizado para el desarrollo

Descripcin
Usado

para

eloborar

Software

Versin

el

MySQL Workbench

06/02/15

el

ArgoUML

0.34

Gestor de base de datos

4.2.7.1

diagrama relacional.
Usado

para

diagrama

de

elaborar

componentes,

diagrama de clases y diagrama

de casos de uso.
Usado

para

manejar

la

administracin de MySql a

PostgresSQL

travs de pginas web.

Usado

para

maquetar

las

HTML/CSS, Javascript,

interfaces

JQuery

Framework de php

Laravel

v5.2

Servidor web Apache

v2.4.10

PHP

5.6

Usado para llevar la base de

datos de escritorio a la web.
Lenguaje de programacin

Metodologa
SCRUM
Detalle de la metodologa
Para el desarrollo del software se opt por una metodologa gil, especficamente
la metodologa SCRUM, ya que se adapta con nuestra diposnibilidad de trabajar y
adems nos hace ms fcil la labor, permitindonos generar pequeos resultados
mediante las iteraciones que se realizan en el desarrollo del software.
Esta metodologa nos permite planificar las iteraciones, asignndole un tiempo de
duracin determinado, el cul hace que nosotros; el equipo de desarrollo, se comprometa
an ms con el proyecto.

Captulo 4

Desarrollo del proyecto

Recursos humanos
Formacin del grupo de trabajo

Tabla 2: Distribucin del equipo de desarrollo

Roles

Responsables

Responsabilidades
Es la figura clave en la planificacin,
ejecucin y control del proyecto. Es el
encargado

de

encaminar

al

equipo,

coordinar los recursos empleados, el

Jefe de Proyecto Luis Miguel Castillo

responsable de que el software se llegue a

realizar de manera correcta, transparente y
de acuerdo a los requerimientos del
cliente.
Es

el

responsable

de

entender

las

necesidades del cliente y asegurarse de

Analista

Kevin Osmar Flores Chambilla

Yuly Choque Ramo

que

la

solucin

que

est

siendo

desarrollada se ajusta a esas necesidades.

Se encarga de hacer la elicitacin de
requisitos y de redactar especificaciones
funcionales.

Luis Miguel Castillo Mamani

Base de Datos

Henrry

Perfecto

Cachicatari

Mamani

Es el encargado de generar el diseo

arquitctonico del sistema en base a los
requisitos.

Asmismo

se

encarga

de

desarrollar los diferentes diagramas y

generar la base de datos del sistema.

Diseador
Grfico

Jesus Qquehue Cuchillo

Es el encargado de realizar las interfaces

Kevin Osmar Flores Chambilla

para las ventanas que tendr la aplicacin.

Esto puede ir desde el diseo completo de

la interfaz de usuario, hasta el difinir slo
algunas directrices de interfaz de usuario.
Es
Programador

el

encargado

de

realizar

la

Luis Miguel Castillo Mamani

programacin del software. Adems, es el

Henrry Cachicatari Mamani

nico que conoce los pensamientos e ideas

detrs del cdigo que escribe, por lo tanto,
tiene que documentar el mismo.
Las pruebas son una parte importante para
asegurar que el software funciona de la
manera que debera, por lo tanto, el Tster

Tester

Jesus Manuel Qquehue Cuchillo

realiza el testeo propiamente dicho con la

finalidad de evaluar el funcionamiento del
software

corregir

posibles

errores

hallados durante este proceso.

Es

el

encargado

de

mantener

la

informacin generada durante los distintos

Documentador

Kevin Osmar Flores Chambilla

procesos de desarrollo de software. Si la

Yuly Choque Ramos

informacin no es lo suficientemente
clara, puede generar conflictos. Por eso,
este rol es de suma importancia.
Es el encargado de explicar cmo la
aplicacin resuelve el problema del cliente

Capacitador

Yuly Sandra Choque Ramos

y, como tal, juega un papel importante en

asegurar que las expectativas del cliente
sobre el software estn en lnea con lo que
ha sido creado.

Calendarizacin del proyecto

Figura 8: Calendarizacin del Proyecto

Figura 9: Muestra de diagrama

Producto Backlog
La hemos organizado en el trello

Figura 10: Los requerimientos

Figura 11: Tareas que se planearon hacer primero

Figura 12: tareas que se estn haciendo y las que ya se hicieron primera semana

Figura 13: avance de la segunda semana

Figura 14: Avance segn calendarizacin

Reuniones
Principalmente se realizaron dos tipos de reuniones que engloba la metodologa
Scrum: Reunin de Planificacin del Sprint y Reunin de Revisin del Sprint.

Adicionalmente se opt por realizar una variante propia de reunin, que engloba
ciertos aspectos del resto de tipos de reuniones. Para tal efecto se tomarn las siguientes
consideraciones:
o

sbado 8:00 am 11:00 am

martes 6:00 pm 8:00 pm

viernes 7:00 pm 8:00 pm

Validacin de diagramas de casos de Uso

Figura 15: CUS general del Sistema

Descripcin de los diagramas de casos de uso

Registrar paciente

Tabla 3: CUS registrar paciente

Nombre

Registrar paciente

Instancia de los usuarios Medico (Administrador)

participantes (actores)
Flujo Principal

Eventos Actor
El

usuario

Eventos Sistema
ingresara

un El sistema, a travs del formulario

formulario a pedir datos del de registro guardara al paciente y

paciente para su registro de lo validara como nuevo paciente,
atencin. Para ello pide datos donde ser guardado en la base de
bsicos

tratamientos

enfermedades
ya

o datos

hechos

anteriormente.
Precondicin

Iniciar sesin de medico

Importancia

Necesaria

Frecuencia esperada

Cada hora

Agendar cita

Tabla 4: CUS Agendar Cita

Nombre

Agentar Cita

Instancia de los usuarios Usuario (Administrador)

participantes (actores)
Flujo Principal

Eventos Actor

Eventos Sistema

El usuario verifica los das libres El sistema mostrara un calendario

para agendar una prxima cita al de fechas y horas disponibles para

paciente.

dar alternativas de prximas citas

Precondicin

El paciente tiene que estar registrado

Postcondicin

Paciente con fecha de cita

Importancia

Importante

Frecuencia esperada

Cada hora

Buscar Cita Previa

Tabla 5: CUS Buscar cita previa

Nombre

Buscar Cita Previa

Instancia de los usuarios Usuario (Administrador)

participantes (actores)
Flujo Principal

Eventos Actor

Eventos Sistema

El usuario solicita al sistema el El sistema responde a la solicitud

formulario la agenda de citas del del cliente y muestra el formulario
paciente. Con el fin de verificar de citas del paciente. Una vez
si tiene cita disponible a su verificado que su cita es vlida y
pronta atencin.
Precondicin

Ser paciente Registrado

Postcondicin

la atencin del paciente con cita

Importancia

Importante

Frecuencia esperada

Casi siempre

Programar cita

ejecutada, procede a su atencin.

Tabla 6: CUS Programar citas

Nombre

Reprogramar Cita

Instancia de los usuarios Usuario (Administrador)

participantes (actores)
Flujo Principal

Eventos Actor

Eventos Sistema

En caso que el cliente no llegue a El sistema ingresa a la agenda del

su cita ordinaria se reprograma paciente recibiendo una fecha a
una cita con la decisin del reprogramar y la ejecuta.
mdico y del paciente. Entra al
sistema y reprograma una nueva
fecha
Precondicin

El paciente tiene que estar registrado

Postcondicin

Actualizacin de cita del paciente

Importancia

Importante.

Frecuencia esperada

Raras veces

Consulta mdica

Tabla 7: CUS consulta mdica

Nombre

Consulta Medica

Instancia de los usuarios Usuario (Administrador)

participantes (actores)
Flujo Principal

Eventos Actor

Eventos Sistema

El usuario solicita al sistema la El sistema verifica la fecha de cita

verificacin del paciente si est del paciente, si est a la hora se
en su cita a la hora para proceder realiza

atencin guardando

la

a su atencin. Luego de su fecha y los avances de la atencin

revisin el medico sacara sus realizada, si no, se le notificara al

conclusiones

curacin

tratamiento,

realizar

una mdico que no debe realizar

de atencin a ese paciente.

acuerdo a sus daos encontrados.

Alternativa

Si el paciente no est a su cita actual, pues se le notifica a qu hora es

su cita o sino a su reprogramacin de cita

Precondicin

El usuario tiene que estar registrado

Postcondicin

La atencin del cliente y su diagnostico

Importancia

Importante.

Frecuencia esperada

En cada cita

Realizar Tratamiento
Tabla 8: CUS Realizar Tratamiento
Nombre

Realizar Tratamiento

Instancia de los usuarios Usuario (Administrador)

participantes (actores)
Flujo Principal

Eventos Actor

Eventos Sistema

El paciente debe decidir si El sistema buscara al usuario y lo

hacerse el tratamiento o no. En seleccionara para crear un historial
caso que si decida hacrselo pues clnico y un odontograma a este
se le crea procesos de trabajos paciente, en seguidamente acordar
para su tratamiento. Se registra una prxima cita al paciente y
un

historial

clnico

un guardarlo a su odontograma.

odontograma al paciente.
Alternativa

Sucede que el paciente decide luego de un tiempo y se acerca al medico

a decirle que quiere realizar su tratamiento, entonces el sistema busca al
paciente y procede a los eventos del sistema

Precondicin

Paciente Registrado

Postcondicin

Paciente con Tratamiento

Importancia

Vital.

Frecuencia esperada

Raras veces
Fuente: Elaboracin propia

Historial Clnico
Tabla 9: CUS Historial Clnico
Nombre

Historial Clnico

Instancia de los usuarios Usuario (Administrador)

participantes (actores)
Flujo Principal

Eventos Actor

Eventos Sistema

El medico espera la decisin del El sistema Crea esta seccin de

paciente

para

realizar

el historial

clnico

del

paciente

tratamiento, y cuando eso pasa el registrando los datos del paciente,

sistema

crea

este

CUS enfermedades

datos

de

obteniendo datos del paciente de tratamientos que realizo antes.

sus enfermedades o tratamientos
hechos anteriormente
Precondicin

Paciente Registrado

Postcondicin

La actualizacin de historia clnica del paciente

Importancia

Importante

Frecuencia esperada

1 ves por paciente

Fuente: Elaboracin propia

Odontograma
Tabla 10: CUS Odontograma
Nombre

Odontograma

Instancia de los usuarios Usuario (Administrador)

participantes (actores)
Flujo Principal

Eventos Actor

Eventos Sistema

El medico va actulizando los El sistema genera una seccin de

avances realizados en cada cita al odontograma del paciente y asi ir
paciente en esta seccin de registrando los datos de cada cita
Odontograma
importante

del

que

es

sistema,

parte y sus avances.

pre-

visualizando los avances.

Precondicin

Paciente Registrado

Postcondicin

Registro de avances realizados por cita

Importancia

Vital.

Frecuencia esperada

Por cada Cita se actualiza

Fuente: Elaboracin propia

Base de datos del sistema: Diagrama entidad-relacin

Descripcin de las entidades del diagrama entidad-relacin

Entidad Persona:

Figura 16: Descripcin de la entidad persona

La persona es la entidad que es directamente relacional con el odontlogo,

ya que est es el paciente de la clnica, asimismo se muestran en la imagen todos

los atributes que esta posee.

Entidad Odontlogo:

Figura 17: Descripcin de la entidad Odontlogo

El odontlogo es el que participa en la operacin de atiende a persona, asimismo

se muestra su nico atributo del odontlogo.

Entidad Historia Clnica:

Figura 18: descripcin de entidad clnica

La entidad Historia Clnica se relaciona con la persona, haciendo que esta sea
nica para una persona y una persona posea solo una historia clnica, asimismo los
atributos son los que se muestran en la ilustracin.
Entidad Tratamiento:

Figura 19: Descripcin de TRatameinto

La entidad Tratamiento se relaciona con la Historia Clnica haciendo que cada Historia
posea muchos tratamientos. Asimismo en la ilustracin se muestran los atributos de la
entidad.

Entidad Pieza:

Figura 20: Descripcin Pieza

La entidad Pieza se relaciona con el tratamiento, esta entidad representa uno de todos los
dientes que posee una persona, asimismo los atributos de esta se observan en la
ilustracin figurada.

Entidad diente_div:

Figura 21: Descripcin del diagram diente div

La entidad diente_div se relaciona con pieza, esta entidad representa las 5 particiones que
el odontlogo figura en el odontograma de cada diente haciendo ms fcil diferenciar el
tratamiento para cada uno de estos, asimismo los atributos de esta se observan en la

ilustracin mostrada.

Descripcin de las relaciones en el diagrama entidad-relacin:

Relacin Atiende

Figura 22: Descripcin E-R atiende

La relacin Atiende es la que interviene el Odontlogo, hace dar a conocer cual
odontlogo se est encargando de que persona, solo un doctor puede dar seguimiento a
cada paciente.

Relacin Posee (Persona Historia Clnica):

Figura 23: descripcin de la Relacin Posee (Persona Historia Clnica)

La relacin posee entre Persona e Historia Clnica indica que una persona posee una sola
historia clnica y viceversa, haciendo de esta manera la duplicidad de informacin.

Relacin Posee (Historia Clnica Tratamiento):

Figura 24: Descripcin de la Relacin Posee (Historia Clnica Tratamiento)

La relacin posee entre ambas entidades indica que una historia clnica puede poseer
muchos tratamientos que fueron aplicados a uno o muchos dientes (pieza).

Relacin Aplica:

Figura 25: Descripcin de la relacin Aplica

La relacin Aplica se relaciona con las entidades tratamiento y pieza, esta relacin define
el tratamiento que recibe cada diente de la persona.

Relacin Posee (Pieza Diente_div):

Figura 26: Descripcin de la Relacin Posee (Pieza Diente_div)

La relacin posee entre pieza y diente_div significa que una pieza esta subdividida en 5
pequeas piezas para poder diferenciar dentro del odontograma.

Diagrama del modelo relacional

Figura 27: Diagrama del modelo relacional

Descripcin de las tablas del modelo relacional

Tabla est_civil

Nombre de la Tabla: Cliente

Fecha de creacin: 30/05/2016

Descripcin: Tabla que contendr los datos de estado civil de una persona.
Campo

Tipo de

Idest_civil
Estado

Dato
int
varchar

Relaciones:

Tama Descripcin
o
20

Clave nica de registro de est_civil

Tipo de estado civil existentes.
Campo clave:
Idest_civil

Fuente: Elaboracin propia

Tabla Persona

Nombre de la Tabla: Persona

Fecha de creacin: 30/05/2016

Descripcin: Tabla que contendr los datos personales de una persona.

Campo

Tipo de

Idpersona
Apellido
Nombre
Sexo
Fech_nac

Dato
int
varchar
Varchar
Int
DateTime

Direccin
Telfono
Ocupacin
Correo

Varchar
Int
Varchar
Varchar

Tama Descripcin
o
20
30

100
50
45

Clave nica de registro de persona

Apellidos de la persona.
Nombres de la persona.
Sexo de cada persona.
Fecha de nacimiento de cada
persona.
Domicilio de cada persona.
Telfono de la persona.
Ocupacin de la persona.
Correo electrnico de la persona.

Relaciones:

Campo clave:

Idest_civil

Idpersona

Idodontlogo
Fuente: Elaboracin propia

Tabla odontlogo

Nombre de la Tabla: Odontlogo

Fecha de creacin: 30/05/2016

Descripcin: Tabla que contendr los datos de un odontlogo.

Campo
Idodontolog

Tipo de
Dato
int

Tama Descripcin
o
Clave

nica

de

registro

de

odontlogo

Relaciones:

Campo clave:
Idodontlogo
Fuente: Elaboracin propio

Tabla Antecedente:

Nombre de la Tabla: Antecedente

Fecha de creacin: 30/05/2016

Descripcin: Tabla que contendr los datos de los antecedentes.

Campo
Idanteceden
te
Tipo_antece

Tipo de
Dato
int
Varchar

Tama Descripcin
o
Clave
60

nica

de

registro

antecedente.
Antecedentes de enfermedades.

den
Relaciones:

Campo clave:
Idantecedente
Fuente: Elaboracin propia

de

Tabla Citas

Nombre de la Tabla: Citas

Fecha de creacin: 30/05/2016

Descripcin: Tabla que contendr los datos de las citas.

Campo
Idcitas
Prox_cita

Tipo de
Dato
int
DateTime

Tama Descripcin
o
Clave nica de registro de citas.
Fecha prxima de la cita de la
persona.

Relaciones:

Campo clave:

Idhist_clinica

Idcitas
Fuente: Elaboracin propia

Tabla Historia Clnica

Nombre de la Tabla: Hist_clinica

Fecha de creacin: 30/05/2016

Descripcin: Tabla que contendr los datos de las Historias clnicas.

Campo
Idhist_clinica

Tipo de
Dato
int

Tama Descripcin
o
Clave nica de registro de Historias

Fech_creacio

DateTime

Clnicas.
Fecha de la creacin de la Historia.

n
Fech_ult_exo

DateTime

Fecha de la ltima exodoncia.

d
Prox_fecha

DateTime

Fecha de la prxima revisin de la

persona.

Relaciones:

Campo clave:

Idantecedente

Idhist_clinica

IdTratamiento
IdPersona
Fuente: Elaboracin propia

Tabla Tratamiento

Nombre de la Tabla: Tratamiento

Fecha de creacin: 30/05/2016

Descripcin: Tabla que contendr los datos de los tratamientos.

Campo

Tipo de

Idtratamient

Dato
int

o
Fecha
Diag
Trata
Nro_sesione

DateTime
Varchar
Varchar
Int

Tama Descripcin
o
Clave

50
50

nica

de

registro

de

tratamientos.
Fecha del tratamiento aplicado.
Diagnstico del diente analizado.
Tratamiento a realizar.
Cantidad de veces que asisti al
dentista.

Relaciones:

Campo clave:

IdPiezas

Idtratamiento

IdPersona
Fuente: Elaboracin propia

Tabla Pieza:
Nombre de la Tabla: Pieza

Fecha de creacin: 30/05/2016

Descripcin: Tabla que contendr los datos de las Piezas.

Campo

Tipo de

Idpieza
Tipo_pieza

Dato
int
Varchar

Tama Descripcin
o

Relaciones:

Clave nica de registro de Pieza.

Nombre del diente.
Campo clave:
Idpieza
Fuente: Elaboracin propia

Tabla Diente_div:
Fuente:

Elaboracin

propia

Interfaces 2.0 promidentodontology

Login:
El sistema mostrar un control para el usuario que desee acceder al sistema y
realizar las acciones propias del sistema.
El administrador deber colocar su respectivo correo electrnico y contrasea que
ha designado para su ingreso.
Por Ejemplo:
Correo electrnico
Contrasea

: Fainesis@gmail.com
: 123456

Figura 28: Login de Sistema Odontolgico Promident.

Olvid mi contrasea
Por seguridad y precaucin olvide mi contrasea muestra la opcin de poder
cambiar tu contrasea y poder ingresar al sistema.

Figura 29: Interfaz de recuperar contrasea mediante correo electrnico.

Mensaje a tu Correo Electrnico

Inmediatamente, en cuestin de segundos un mensaje llegar a tu bandeja de
correo para poder realizar el cambio de tu contrasea. Te redirigir con una
direccin del sistema para poder realizar tus cambios.

Figura 30: Mensaje de cambio de contrasea.

Cambio de contrasea
Tendrs la opcin de cambiar tu contrasea con toda seguridad, si la confirmacin
del correo es correcta podrs realizar tus cambios de contrasea.

Figura 31: Interfaz de cambio de contrasea.

Men Principal

Pgina principal del sistema, ser la portada inicial que mostrar el sistema y vera
el usuario.

El Nav o barra superior: mostrar el nombre del sistema y el usuario que

esta usndolo.
Sidebar o Barra de Navegacin: se mostrar todas las pestaas que se
tengan y registros, dentistas entre otros.
Footer o Pie de Pgina: Mostrar enlaces alternativos y referentes al
sistema, enlaces en redes sociales.
Home o Cuerpo: se pondr lo ms resaltante del sistema, atenciones,
visitas, calendario, etc.

Seccin Dentista
Mostrara todos los usuarios ya registrados que tienen el acceso al sistema.

Figura 32: Listado de dentistas

a. Registrar Dentista
Solo el administrador podr registrar a los nuevos dentistas y colaboradores
del consultorio Promident.
Rellenando los campos del formulario.
Adicionalmente se opt por realizar una variante propia de reunin, que engloba
ciertos aspectos del resto de tipos de reuniones. Para tal efecto se tomarn las
siguientes consideraciones:

Figura 33: Interfaz registrar dentista

BIBLIOGRAFIA

ANEXOS

a) Diagrama de Actividad: Registra paciente

b) Diagrama de Secuencia: Registra paciente

c) Diagrama de Colaboracin: Registra paciente

d) Diagrama de Actividad: Buscar Cita previa

e) Diagrama de Actividad: Agendar Cita

f) Diagrama de Secuencia: Agendar Cita

g) Diagrama de Colaboracin: Agendar Cita

h) Diagrama de Actividad: Reprogramar Cita

i) Diagrama de Secuencia: Reprogramar Cita

j) Diagrama de Colaboracin: Reprogramar Cita

k) Diagrama de Actividad: Consulta medica

l) Diagrama de Secuencia: Consulta medica

m) Diagrama de Colaboracin: Consulta medica

n) Diagrama de Actividad: Realizar tratamiento

o) Diagrama de Secuencia: Realizar tratamiento

p) Diagrama de Colaboracin: Realizar tratamiento

q) Diagrama de Actividad: Historial Clnico

r) Diagrama de Secuencia: Historial Clnico

s) Diagrama de Colaboracion: Historial Clnico

t) Diagrama de Actividad: Odontograma

u) Diagrama de Secuencia: Odontograma

v) Diagrama de Colaboracin: Odontograma