Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Odonto Grama 2
Odonto Grama 2
Proyecto de grado como requisito para optar por el título de Ingeniero de Sistemas.
ASESOR
EMILIO BARAJAS
INGENIERO DE SISTEMAS
_________________________
_________________________
_________________________
_________________________
Presidente del Jurado
_________________________
Firma del Jurado
_________________________
Firma del jurado
2
Dedico mi trabajo al Dios de la vida, que me ha dado una nueva oportunidad de vivir. A mi
familia por todo su apoyo incondicional y todos aquellos que de una u otra manera han
apoyado mi estudio y han sido oportunos con sus consejos y sugerencias.
Mis padres, Juan Antonio y María Ruth han sido ejemplares en la comunicación de
valores, de ellos aprendí la perseverancia, la constancia, la dedicación y el valor mostrado
para salir adelante. Gracias papás por su amor.
A Gabriel por haberme apoyado en todo momento, por sus exigencias, pero más que
nada, por su comprensión. A mi compañera de tesis, que gracias al equipo y la unidad
que formamos, logramos llegar hasta el final.
A Dios por darme la oportunidad que me brindo al llegar hasta aquí, a mis padres y familia
porque sin su apoyo incondicional este paso en mi vida no hubiese sido posible de
alcanzar, a mis amigos que siempre me dieron una voz de aliento y de ánimo para no
desfallecer en este proceso y a mi compañera Natalia por su colaboración, esfuerzo y
constancia para terminar con éxito el propósito que nos unió.
3
TABLA DE CONTENIDO
INTRODUCCIÓN..............................................................................................................13
1. PLANTEAMIENTO DEL PROBLEMA ......................................................................14
1.1. ANTECEDENTES (ESTADO DEL ARTE) ...............................................................14
1.2. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA .............................................15
1.3. JUSTIFICACIÓN .....................................................................................................15
1.4. OBJETIVOS ............................................................................................................17
1.4.1. Objetivo General....................................................................................................17
1.4.2. Objetivos Específicos. ...........................................................................................17
1.5. ALCANCES Y LIMITACIONES ................................................................................17
1.5.1. Alcances................................................................................................................17
1.5.2. Limitaciones...........................................................................................................18
2. METODOLOGÍA......................................................................................................20
3. LÍNEA DE INVESTIGACIÓN ...................................................................................21
3.1. ENFOQUE DE LA INVESTIGACIÓN .......................................................................21
3.2. LÍNEA DE INVESTIGACIÓN DE USB .....................................................................21
3.3. SUB-LÍNEA DE FACULTAD ....................................................................................21
3.4. CAMPO TEMÁTICO DEL PROGRAMA...................................................................21
4. MARCO DE REFERENCIA .....................................................................................22
4.1. TEÓRICO CONCEPTUAL .......................................................................................22
4.1.1. Metodología de Desarrollo de Software .................................................................22
4.1.2. Servidor de Aplicaciones .......................................................................................25
4.1.3. Base de Datos. ......................................................................................................27
4.1.4. Plataforma J2EE....................................................................................................29
4.1.5. JavaBean. .............................................................................................................31
4.1.6. SMS (Short Message Service)...............................................................................31
4.1.7. Administración de la Historia Clínica Odontológica. ...............................................32
4.1.8. Proceso para solicitar una cita odontológica ..........................................................33
4.2. MARCO LEGAL O NORMATIVO.............................................................................34
4.2.1. RESOLUCIÓN NÚMERO 1995 DE 1999 (JULIO 8) ..............................................34
4
5. DESARROLLO INGENIERIL ...................................................................................35
5.1. METODOLOGÍA DEL PROYECTO .........................................................................35
5.2. ANÁLISIS Y DEFINICIÓN DE REQUERIMIENTOS.................................................35
5.2.1. Levantamiento de información. ..............................................................................35
5.2.2. Requerimientos funcionales...................................................................................36
5.2.3. Requerimientos no funcionales..............................................................................38
5.3. DISEÑO DEL SISTEMA Y DE SOFTWARE. ...........................................................39
5.3.1. Diseño del sistema. ...............................................................................................39
5.3.1.2. Diagramas de casos de uso................................................................................40
5.3.2. Diseño del software. ..............................................................................................54
5.4. IMPLEMENTACIÓN Y PRUEBA DE UNIDADES....................................................83
5.4.1. Implementación. ....................................................................................................83
5.4.2. Prueba de Unidades. .............................................................................................95
5.5. INTEGRACIÓN Y PRUEBAS DEL SISTEMA. ......................................................101
5.6. FUNCIONAMIENTO Y MANTENIMIENTO ...........................................................105
6. PRESENTACIÓN Y ANÁLISIS DE RESULTADOS ..............................................106
CONCLUSIONES...........................................................................................................109
RECOMENDACIONES...................................................................................................110
BIBLIOGRAFÍA ..............................................................................................................111
WEBGRAFÍA..................................................................................................................113
GLOSARIO ODONTOLÓGICO ......................................................................................115
GLOSARIO TÉCNICO....................................................................................................116
5
LISTA DE TABLAS
6
Tabla 24. Estudio..............................................................................................................69
7
Tabla 49. Caso de Prueba Registrar Usuario con datos no válidos. ...............................102
8
LISTA DE FIGURAS
9
Figura 23. Propiedades de la base de datos.....................................................................86
10
LISTA DE GRÁFICAS
11
LISTA DE ANEXOS
12
INTRODUCCIÓN
Según Roger S. Pressman en su libro Ingeniería del Software (un enfoque práctico): “las
Aplicaciones Web o WebApps son diferentes de otras categorías de software informático;
son eminentemente en red, las gobiernan los datos y se encuentran en evolución
continua. Las WebApps pueden valorarse mediante una diversidad de criterios de calidad
que incluyen facilidad de uso, funcionalidad, confiabilidad, eficiencia, capacidad de
mantenimiento, seguridad, disponibilidad y escalabilidad”.
El aplicativo contará con SMS (Short Message Service), servicio por medio del cual se
utiliza el sitio web para enviar a través de internet un mensaje al teléfono móvil de cada
paciente, recordando el día y la hora de su próxima cita odontológica. Adicionalmente la
implementación se hará con un servidor de aplicaciones Java, sobre una plataforma J2EE
(Java 2 Enterprise Edition). Este estándar permite el desarrollo de aplicaciones de una
manera eficiente y versátil.
13
1. PLANTEAMIENTO DEL PROBLEMA
Otra alternativa de software dental es DentiLogic2, el cual posee todas las herramientas
que se necesitan para gestionar una clínica odontológica en un entorno intuitivo y
amigable, mientras que el sistema se encarga de procesos complejos y rutinarios. Aunque
este software tiene un costo comercial de $1.265.000 anual, que puede ser considerado
alto para un consultorio odontológico promedio.
Al mismo tiempo Dental Pro3 es otro software que da el control completo sobre los
tratamientos odontológicos de los pacientes en el Consultorio. Base de Datos Profesional
pensado tanto para principiantes como para profesionales, lleva el control de: Pacientes,
Historias Clínicas, Presupuestos, Pagos y/o Abonos, Tratamientos y/o Trabajos Dentales,
Agenda de Citas, Estado de Cuenta, Fotos e Imágenes, Recetas Médicas y Trabajos de
Laboratorio.
1
Pro practica, [artículo en línea] Disponible desde Internet en: <http://propractica.tripod.com/>,Mayo 15 de 2010.
7:30pm.
2
Dentilogic, [artículo en línea] Disponible desde Internet en: <https://www.dentilogic.com/acm/es/dl/About.htm>, Mayo
15 de 2010. 8:30pm.
3
Dental Pro, [artículo en línea] Disponible desde Internet en: <http://www.digitalab-software.com/consultorio>, Mayo 15
de 2010. 8:40pm.
14
Finalmente existe Galeno Dental4 que se dedica al almacenamiento e identificación de
imágenes y videos, registro personalizado y manipulación precisa de imagen,
administración de todas las citas, horarios y consultorios.
1.3. JUSTIFICACIÓN
Las clínicas necesitan un sistema de información que permita crear una historia
odontológica para almacenar los datos de cada paciente, hacer un seguimiento de su
tratamiento, evolución y procedimientos realizados de una manera más ágil.
4
Galeno Dental, [artículo en línea] Disponible desde Internet en: <http://www.galeno.com.mx/main/index.php>, Mayo 15
de 2010. 9:30pm.
15
Las ventajas de Dentistry Web con respecto a los mencionados en la tabla 1 son el bajo
costo de las herramientas de desarrollo. Asimismo la aplicación contará con una interfaz
web cuyo beneficio es que se puede acceder a un servidor web a través de internet lo
cual significa que no se instala el software en varias pc’s.
Manejo de citas Si Si Si
Manejo de historias Si Si Si
Interfaz web No Si Si
Usabilidad Si Si Si
Los beneficios que se pueden encontrar en el aplicativo son: Tener un manejo del tiempo
eficiente en una consulta odontológica, proporciona información inmediata sobre las
historias clínicas odontológicas. Con la implementación del aplicativo web se va a tener un
control de toda la información relacionada con los pacientes (datos personales, historia
odontológica, antecedentes personales y familiares, tratamiento a realizar, procedimientos
realizados y programación de sus citas). Su uso permitirá administrar de manera eficiente
la información odontológica de los pacientes, llevar un registro organizado del historial
odontológico permitiendo una búsqueda ágil y fácil.
1.4. OBJETIVOS
Esta aplicación contará con varios menús en los que se puede encontrar el paciente con
toda su información personal y de contacto (nombre, apellidos, tipo documento de
identidad, documento de identidad, fecha de nacimiento, género, ocupación, estado civil,
barrio, teléfono y celular). También permitirá agregar nuevos pacientes, actualizar, editar
17
sus datos personales y generar reportes. Además en la historia odontológica de cada
paciente se puede seleccionar un plan de tratamiento adecuado a realizar y almacenar
sus procedimientos realizados anteriormente.
Permitirá crear citas semanales asignando cada una de ellas en un lapso de treinta
minutos y donde se puede consultar disponibilidad de odontólogos y horarios.
Un valor adicional con el que contará la aplicación web es el SMS, servicio por medio del
cual se puede enviar a través de internet un mensaje al teléfono móvil de cada paciente,
recordando el día y la hora de su próxima cita odontológica. Además el paciente se podrá
comunicar con la clínica telefónicamente donde se le dará respuesta a cualquier inquietud
o solicitud que esté presente.
18
El sistema de SMS se implementará a través de un proveedor de servicios de mensajería,
este servicio depende si el consultorio lo desea implementar.
El aplicativo no contará con el servicio de adicionar ninguna opción diferente a las que se
encuentran establecidas en el formato de la historia clínica detallado en el anexo B.
19
2. METODOLOGÍA
En el diseño del sistema del software es necesario escoger un motor de base de datos
que permita almacenarlos, en este caso se escogió My Sql 5.1 ya que es la herramienta
sobre la cual se tiene más conocimiento, es de fácil uso, rápido y lo más importante es
que es un software libre.
Para la fase de implementación, la plataforma J2EE permite crear un escenario ideal para
el desarrollo y despliegue de aplicaciones escalables en la Web, esto hace que se
reduzcan los costos.
El envío de un Sms es un servicio adicional, que hoy en día es uno de los mejores medios
para comunicarse. Se usa en la aplicación para recordar al paciente la hora y fecha de su
próxima cita.
Netbeans IDE 6.7 es el entorno de desarrollo visual de código abierto para aplicaciones
programadas mediante Java, uno de los lenguajes de programación más poderosos del
momento y el cual se usará para el desarrollo esta aplicación.
20
3. LÍNEA DE INVESTIGACIÓN
21
4. MARCO DE REFERENCIA
Para alcanzar los objetivos propuestos en el desarrollo del aplicativo web se escogió la
siguiente metodología que servirá para dar respuesta al problema que se ha planteado.
Según Alfredo Weitzenfeld “El modelo de cascada se define como una secuencia de
actividades, donde la estrategia principal es seguir el progreso del software hacia puntos
de revisión bien definidos mediante entregas calendarizadas”5.
2. Diseño del sistema y del software: El proceso de diseño del sistema divide los
requerimientos en sistemas hardware y software. El diseño del software identifica
y describe las abstracciones fundamentales del sistema software y sus relaciones.
5
WEITZENFELD, Alfredo, Ingeniería de Software. México Thomson 2005. p678.
22
4. Integración y pruebas del sistema: El software obtenido se pone en producción.
Se implantan los niveles software y hardware que componen el proyecto. Durante
la explotación del sistema de software pueden surgir cambios, bien para corregir
errores o bien para introducir mejoras. Después de las pruebas el sistema software
se entrega al cliente.
6
SOMMERVILLE, Ian, Ingeniería del Software, Pearson Educación S.A. Madrid 2005, p 62.
23
Tabla 2. Metodologías de Desarrollo de Software.
METODOLOGÍAS FASES DEFINICIÓN TIEMPO DE MANTENIMIENTO
EJECUCIÓN
24
Como metodología de desarrollo se escogió el modelo en Cascada porque permite hacer
modificaciones en el diseño lo cual significa que se harán cambios en la codificación y se
tendrán que realizar de nuevo las pruebas. En esta metodología el tiempo de ejecución se
lleva a cabo en mediano plazo lo cual es una ventaja para el desarrollo del proyecto.
7
¿Qué es un servidor de aplicaciones?, [artículo en línea] Disponible desde Internet en: <
http://updateycommit.blogspot.com/2010/08/diferencia-de-servidor-de-aplicaciones.html>, Marzo 21 de 2010. 9:30am.
25
Tabla 3. Servidor de Aplicaciones.
Modularidad.
Tiempo mejorado de inicio. Servidor de aplicaciones desarrollado por Oracle Corporation que implementa las
tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones
GLASSFISH Despliegues desde plugins en NetBeans y Eclipse, que siguen esta especificación.
y preservación de sesiones a través de
redespliegues.
26
En la tabla 3 se encuentran algunos servidores de aplicaciones existentes haciendo una
comparación entre las características que poseen para determinar el que más se ajuste a
las necesidades de la aplicación. Por consiguiente, se escogió Apache Tomcat 6.0 porque
incluye un servidor web que abarca todas las funcionalidades de los JSP’s y además es la
herramienta sobre la cual se tiene más conocimiento.
4.1.3. Base de Datos. Para el almacenamiento de datos, la plataforma requiere una base
de datos que sea accesible a través de JDBC (Java Database Connectivity). Esto se hace
a través desde los componentes web y los componentes de la aplicación cliente.
Uno de los beneficios de las Bases de datos es que el servidor puede manejar
transacciones, la seguridad, escalabilidad, concurrencia.
Como lo afirma Daniel Pecos, “MySql es el gestor de bases de datos más usado en el
mundo del software libre, debido a su gran rapidez y facilidad de uso. Ésta contiene
infinidad de librerías y otras herramientas que permiten su uso a través de gran cantidad
de lenguajes de programación, además de su fácil instalación y configuración”.8
8
MySql, [artículo en línea] Disponible desde Internet en: <http://danielpecos.com/docs/mysql_postgres/x57.html>, Marzo
25 de 2010. 6:10pm.
27
Tabla 4. Motor de Base de Datos.
Relacional Aproxima los datos a PgAdmin3 : entorno de Protección de los ficheros de la base de
un modelo objeto- escritorio Visual datos.
relacional, y es PgAccess : entorno de Las conexiones de los clientes al servidor
capaz de manejar escritorio Visual de la base de datos están permitidas, por
complejas rutinas y PhpPgAdmin : entorno defecto.
reglas. Web Las conexiones de los clientes se pueden
POSTGRES Soporta integridad restringir por dirección IP y/o por nombre
psql : cliente de consola
referencial, la cual de usuario mediante el fichero
es utilizada para pg_hba.conf situado en PG_DATA.
garantizar la validez
de los datos de la
base de datos.
Relacional Aprovecha la TurboDbAdmin MySQL Network Scanner: Este programa
potencia de EMS SQL Manager for permite auditar una red de clase C en
sistemas MySQL busca de servidores MySQL que no
multiprocesador. MySQL GUI Tools tengan definida una contraseña para el
Soporta gran phpMyAdmin usuario root.
cantidad de tipos de Instant SQL Formatter MySQL Brute Force Password Hash
MYSQL datos para Cracker: Esta utilidad, complementaria a la
DB Designer 4
columnas. WWW SQL Designer anterior, admite como argumento el hash
Gestión de usuarios de una contraseña de un usuario de
y passwords. MySQL y, mediante fuerza bruta, intentará
Gran portabilidad descifrarlo.
entre sistemas.
28
4.1.4. Plataforma J2EE. Como lo afirma Felipe Aguilera, J2EE “Es una plataforma creada
por Sun y basada en Java, para el desarrollo de aplicaciones empresariales distribuidas.
J2EE se basa en una arquitectura multicapa para el desarrollo de sistemas”9.
Así mismo, Juan Manuel Barrios dice que dicha arquitectura “se basa en los conceptos de
capas, containers, componentes, servicios y las características de cada uno de éstos. Las
aplicaciones J2EE son divididas en cuatro capas: la capa cliente, la capa web, la capa
negocio y la capa datos. La figura 2 representa estas capas y sus componentes.
Capa Cliente
Capa Web
9
Análisis y diseño orientado a objetos Patrones de diseño, [artículo en línea] Disponible desde Internet en:
<http://www.dcc.uchile.cl/~luguerre/cc40b/clase13.html>, Abril 02 de 2010. 5:10pm.
29
Figura 2. Arquitectura J2EE.
Capa Negocio
Capa Datos
Según Johnson Mark, “La plataforma J2EE no obliga a usar en un sistema todas las
capas. Lo esencial es escoger el mecanismo adecuado para el problema. En este sentido,
en ocasiones no hay la complejidad como para requerir una capa EJB. Se denomina
10
Investigación de la plataforma J2EE y su aplicación práctica [artículo en línea] Disponible desde Internet en: <
http://www.dcc.uchile.cl/~jbarrios/J2EE/node14.html>, Octubre 7 de 2010, 4:01 p.m.
30
escenario web-centric porque el contenedor web es el que realiza gran parte del trabajo
del sistema. En este tipo de escenario la capa web implica tanto lógica de presentación
como lógica de negocio”.11 En la figura 3 se representa el escenario basado en la web
descrito anteriormente.
Autor: Inderjeet Singh,Beth Stearns,Mark Johnson; Designing Enterprise applications with the J2EE
platform.
4.1.6. SMS (Short Message Service). “El SMS permite enviar y recibir mensajes, recibir
notificaciones de correo electrónico, correo de voz y fax integrados, recordatorios, avisos
de retraso de vuelos, noticias, agenda de acontecimientos culturales y el precio de una
llamada que se acaba de hacer. Su ventaja reside en la rapidez y bajo coste. También se
pueden enviar mensajes a móviles desde diferentes portales de Internet”.13
11
SINGH Inderjeet, STEARNS Beth, JOHNSON Mark, Designing Enterprise applications with the J2EE platform, Sun
Microsystem 2002, p19.
12
Definición JavaBean [artículo en línea] Disponible desde Internet en:
<http://www.sc.ehu.es/sbweb/fisica/cursoJava/applets/javaBeans/fundamento.htm#Definición de JavaBean>, Octubre 5
de 2010, 2:23 p.m.
13
Definición SMS, [artículo en línea] Disponible desde internet en: <http://www.sitiosespana.com/notas/febrero-
2005/QUE-ES-SMS.htm>, Octubre 5 de 2010, 2:23 p.m.
31
4.1.7. Administración de la Historia Clínica Odontológica. Para llevar a cabo este
proceso es necesario tener en cuenta las directivas internas, características,
componentes, formatos, instructivos, diligenciamiento, uso y manejo de la historia clínica
odontológica las cuales se encuentran detalladas en el anexo A.
14
Resolución número 1995 de 1999 (julio 8).
32
6. Consentimiento Informado: es la aprobación del paciente a que se le realicen los
procedimientos, dar a conocer los posibles riesgos y complicaciones que se
pueden presentar en el tratamiento.
7. Evolución salud oral: es la parte que indica la fecha, hora, diente y el tratamiento
que se le realizó al paciente.
8. Anexos: son todos aquellos documentos que sirven como sustento legal, técnico,
científico y/o administrativo de las acciones realizadas al usuario en los procesos
de atención, tales como: autorizaciones para intervenciones quirúrgicas
(consentimiento informado), procedimientos, declaración de retiro voluntario y
demás documentos que las instituciones prestadoras consideren pertinentes.
4.1.8. Proceso para solicitar una cita odontológica. El paciente solicita la cita
telefónicamente, se le asigna una fecha y hora con el que esté de acuerdo, este proceso
es igual si el paciente asiste por primera vez o si ya es un usuario habitual del consultorio.
Otra opción para solicitar la cita es hacerlo en el consultorio el mismo día de la consulta.
15
Ejemplo para el manejo de una historia clínica odontológica, [artículo en línea] Disponible desde Internet en:
http://www.saludcapital.gov.co/Publicaciones/doc, Agosto 5 de 2010, 4:01 p.m.
33
4.2. MARCO LEGAL O NORMATIVO
4.2.1. RESOLUCIÓN NÚMERO 1995 DE 1999 (JULIO 8): “por la cual se establecen
normas para el manejo de la historia clínica.
34
5. DESARROLLO INGENIERIL
Para alcanzar los objetivos propuestos con el desarrollo del aplicativo web se escogió la
metodología en cascada que servirá para dar respuesta al problema que se ha planteado
y respaldará su información, ejecución y mantenimiento de modo que cuente con la mejor
calidad, basándose en la Ingeniería de software. Actualmente éste es uno de los más
utilizados por su eficacia y simplicidad, además ayuda a minimizar los gastos de la
planificación.
35
Aporte de los encuestados: La mayoría de los encuestados coincidieron en que para
ellos sería más cómodo, rápido y fácil solicitar o cancelar su próxima cita odontológica por
medio de una página web, ya que en ella se podrá visualizar horarios, fechas y
odontólogos disponibles con su respectiva especialidad. Igualmente todos opinaron en
que les gustaría que se les recordara la fecha y hora de su próxima cita a través de un
mensaje corto de texto en el celular.
16
SOMMERVILLE, Ian, Ingeniería del Software, Pearson Educación S.A. Madrid 2005, p 110.
36
El día que el paciente acude a la consulta se crea una historia odontológica por medio de
un formato el cual contiene 8 secciones, ellas son:
1. Datos personales
2. Examen básico
3. Antecedentes personales y familiares
4. Odontograma
5. Plan de tratamiento
6. Consentimiento informado
7. Evolución
8. Anexos.
En la sección de datos personales el sistema pedirá los datos básicos del paciente
(nombres, apellidos, dirección, teléfono, celular, género, fecha de nacimiento, ocupación,
estado civil y documento de identidad, nombre, dirección y teléfono de la persona
responsable (en el caso que el paciente sea menor de edad.) los cuales se guardarán en
la base de datos creada para este fin. Seguido de esto se dispone a realizar un examen
básico, antecedentes personales y familiares que le permitirán saber las enfermedades
sufridas y la ingestión de medicamentos del paciente, tratamientos realizados, hábitos de
higiene oral, estado general de los dientes lo cual queda consignado en el odontograma.
En la página web los usuarios encontrarán la información sobre los odontólogos (nombres
apellidos, y estudios realizados), servicios que presta el consultorio, dirección y teléfono
de éste. Para el registro de odontólogos el administrador lo realizará en un formulario
diseñado el cual pedirá los datos básicos como nombres, apellidos, cédula, teléfono,
celular, dirección, entre otros. Esto se guardará en la base de datos del sistema.
37
El sistema contará con las siguientes restricciones:
No puede haber dos pacientes registrados con el mismo número de cédula. El número de
historia clínica debe ser consecutivo generado automáticamente por el sistema y por
ningún motivo debe repetirse y por último los pacientes no pueden acceder a la historia
clínica odontológica desde la página web.
17
SOMMERVILLE, Ian, Ingeniería del Software, Pearson Educación S.A. Madrid 2005, p 111.
38
El equipo desde donde se acceda a la aplicación debe tener instalado un
navegador de internet. (Internet Explorer Versión 7 en adelante, Mozilla
Firefox Versión 3.0 en adelante, Opera Versión 8.5 en adelante).
Conocimientos básicos sobre sistemas informáticos de las personas que
interactúan con el sistema.
5.3.1. Diseño del sistema. El diseño del sistema se realizará con los conceptos de UML
(Unified Modeling Language) adquiridos en ingeniería de software, por medio de los casos
de uso. Estos casos representan una interacción típica entre el usuario y el sistema
informático, los cuales permiten establecer la funcionalidad propia del sistema. A
continuación se definen los actores y los casos de usos.
Administrador: es la persona que cuenta con todos los privilegios para gestionar
todos los módulos con los cuales cuenta el sistema (gestionar historia
odontológica, información de pacientes, odontólogos y asistente, y solicitar,
consultar o cancelar citas).
39
consultorio desee implementar el servicio de mensajería. Por último puede
actualizar sus propios datos.
5.3.1.2. Diagramas de casos de uso. Para el desarrollo del sistema Dentistry web se
elaboraron los siguientes diagramas de casos de uso como lo muestran las figuras 4, 5, 6,
7 y 8.
40
Tabla 5. Descripción Caso de Uso Registrar Usuario.
Flujo alternativo de eventos Se debe hacer una validación de los campos registrados.
41
Curso normal de eventos insertados por pantalla.
42
historia.
43
Flujo alternativo de eventos Ninguno.
44
listado de reportes disponibles para los usuarios.
Flujo alternativo de eventos Si los datos de ingreso no son válidos el sistema no muestra
ningún reporte.
45
Figura 5. Diagrama Caso de Uso Administrador.
46
Figura 6. Diagrama Caso de Uso Odontólogo.
47
El usuario debe haber ejecutado el caso de uso autenticar
Precondiciones usuario.
49
Tabla 16. Descripción Caso de Uso Actualizar Historia Clínica.
50
que desee visualizar.
51
La tabla 6 describe el caso de uso de autenticación de los usuarios administrador y
odontólogo.
Actores Asistente.
Curso normal de eventos 1. Se presenta al asistente una opción para enviar sms.
52
3. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Las tablas 6, 11, 12, 13, 14 y 18 describen los demás casos de uso que la asistente
realiza que corresponden a Autenticar Usuario, Cerrar Sesión, Solicitar Cita, Consultar
Cita, Cancelar Cita y Actualizar Datos.
53
La descripción de los casos de uso del paciente ya se encuentra en las tablas 5, 6, 11, 12,
13, 14 y 18; que corresponden a Registrar Usuario, Autenticar Usuario, Cerrar Sesión,
Solicitar Cita, Consultar Cita, Cancelar Cita y Actualizar Datos.
5.3.2. Diseño del software. Para cumplir con la fase de diseño del software se tomaron
los requerimientos funcionales establecidos en la fase de análisis para elaborar el
diagrama de clases, los diagramas de secuencia con su respectiva descripción, los
diagramas de actividades y el modelo de la base de datos con su diccionario el cual
define las tablas que la describen.
18
FALGUERAS Campderrich, Benet, Ingeniería del Software, Editorial UOC. Barcelona 2003, p 38.
54
La figura 9 representa el diagrama de clases que se usan en el aplicativo, cada una con
los atributos, operaciones y relaciones que las componen. Serán implementadas para el
buen funcionamiento del sistema y cumplirán con cada uno de los requisitos establecidos
para este fin. La clase principal es Historia Clínica ya que sin ella el objetivo principal del
aplicativo no se cumpliría. Para mayor facilidad a la hora registrar y consultar la Historia
se dividió en sub clases en las cuales se guarda toda la información que se está
sistematizando y va permitir administrar de una manera sencilla la información de los
pacientes.
19
DEBRAUER, Lauren y VAN DER HEIDE, Fien UML2, Ediciones ENI. Barcelona 2009, p 59.
55
Figura 10. Diagrama de Secuencia Registrar Usuario.
56
Figura 11. Diagrama de Secuencia Crear Historia Clínica.
Para solicitar una cita como se muestra en la figura 12, el usuario (odontólogo, asistente o
paciente) debe autenticarse con usuario y contraseña por medio de la interfaz de
autenticación, luego ingresa los datos requeridos para crear una cita odontológica lo cual
también hace por medio de una interfaz que se ha diseñado, se verifican los horarios y
odontólogos disponibles. Se envía un mensaje confirmando que se ha creado la cita
mostrando en pantalla el día, la hora y el odontólogo. Por último se vuelve al menú
principal.
57
Figura 12. Diagrama de Secuencia Solicitar Cita.
58
Figura 13. Diagrama de Secuencia Enviar SMS.
59
5.3.2.3. Diagrama de Actividades. “Un diagrama de actividades muestra un flujo de
acciones, generalmente secuenciales. Es decir, hay un punto inicial y luego se muestran
las diferentes actividades que se realizan, una tras otra hasta llegar a un punto final. Estos
diagramas son utilizados principalmente para representar procesos del negocio y flujos de
trabajo en un sistema. El diagrama de actividades es un diagrama dinámico, que puede
verse como un diagrama de flujo que muestran los eventos y las decisiones que se toman
al realizar un proceso”.20
20
Definición Diagrama de Actividades, [artículo en línea] Disponible desde Internet en:
<http://www.scribd.com/doc/13735556/ADOO-Diagramas-de-Actividades>, Septiembre 23 de 2010, 8:20 p.m.
60
Figura 15. Diagrama de Actividades Odontólogo y Administrador.
61
Figura 16. Diagrama de Actividades Asistente y Paciente.
Persona
Asistente
Odontólogo
Acudiente
Estudio
Historia clínica
Plan de tratamiento
Examen básico
Diente
Evolución
Anexos
Citas
Servicios
Servicios por odontólogo
Sms
21
RODRIGUEZ ALMEIDA, Miguel Ángel, Bases de Datos. México Mc. Graw Hill. P257.
63
5.3.2.4.1. Modelo de la base de Datos
64
5.3.2.4.2. Diccionario de datos.
Numero_documento: Es la llave primaria de la tabla PACIENTE que se encarga de enlazar esta tabla con las demás.
Tipo_documento: Este campo se refiere a tipo de identificación del paciente.
Nombre: En este campo se almacenan los nombres de los pacientes del sistema.
Apellidos: En este campo se almacenan los apellidos de los pacientes del sistema.
Teléfono: En este campo se almacena el número de teléfono fijo de los pacientes del sistema.
Celular: En este campo se almacena el número de celular de los pacientes del sistema.
Direccion: En este campo se almacena la dirección de los pacientes del sistema.
Genero: En este campo se almacena el género (masculino o femenino) de los pacientes del sistema.
Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los pacientes del sistema.
Login: En este campo se almacena el usuario de los pacientes para poder ingresar al sistema.
Password: En este campo se almacena la contraseña de los pacientes para poder ingresar al sistema.
65
Tabla 21. Asistente.
Numero_documento: Es la llave primaria de la tabla ASISTENTE que se encarga de enlazar esta tabla con las demás.
Tipo_documento: Este campo se refiere a tipo de identificación del asistente.
Nombre: En este campo se almacenan los nombres del asistente.
Apellidos: En este campo se almacenan los apellidos del asistente.
Teléfono: En este campo se almacena el número de teléfono fijo del asistente.
Celular: En este campo se almacena el número de celular del asistente.
Direccion: En este campo se almacena la dirección del asistente.
Genero: En este campo se almacena el género (masculino o femenino) del asistente.
Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los pacientes del sistema.
Cargo: en este campo se almacena el cargo de la asistente, puede ser enfermera, secretaria o solo asistente.
Login: En este campo se almacena el usuario del asistente para poder ingresar al sistema.
Password: En este campo se almacena la contraseña del asistente para poder ingresar al sistema.
66
Tabla 22. Odontólogo
Numero_documento: Es la llave primaria de la tabla ODONTÓLOGO que se encarga de enlazar esta tabla con las demás.
Tipo_documento: Este campo se refiere a tipo de identificación del odontólogo.
Nombre: En este campo se almacenan los nombres del odontólogo.
Apellidos: En este campo se almacenan los apellidos del odontólogo.
Teléfono: En este campo se almacena el número de teléfono fijo del odontólogo.
Celular: En este campo se almacena el número de celular del odontólogo.
Direccion: En este campo se almacena la dirección del odontólogo.
Genero: En este campo se almacena el género (masculino o femenino) del odontólogo.
Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los odontólogos del sistema.
Tarjeta_profesional: En este campo se almacena el número de tarjeta profesional del odontólogo.
Administrador: Este campo se refiere a si el odontólogo es administrador o no.
Login: En este campo se almacena el usuario del odontólogo para poder ingresar al sistema.
Password: En este campo se almacena la contraseña del odontólogo para poder ingresar al sistema.
67
Tabla 23. Acudiente.
Numero_documento: Es la llave primaria de la tabla ACUDIENTE que se encarga de enlazar esta tabla con las demás.
Tipo_documento: Este campo se refiere a tipo de identificación del acudiente del paciente.
Nombre: En este campo se almacenan los nombres del acudiente del paciente.
Apellidos: En este campo se almacenan los apellidos del acudiente del paciente.
Teléfono: En este campo se almacena el número de teléfono fijo del acudiente del paciente.
Celular: En este campo se almacena el número de celular del acudiente del paciente.
Direccion: En este campo se almacena la dirección del acudiente del paciente.
68
Tabla 24. Estudio.
69
Tabla 25. Historia_Clínica.
NOMBRE DE LA TABLA: HISTORIA_CLINICA
Descripción: En esta tabla se almacenan la información que debe llevar la historia clínica odontológica.
Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not Null
Numero_historia X Int 10 X
Antecedente_personal Varchar 40
Antecedente_familiar Varchar 40
Fecha_de_actualizacion Date X
Numero_documento_paciente X Double X
Numero_historia: es la llave primaria de la tabla HISTORIA_CLÍNICA que se encarga de enlazar esta tabla con las demás.
Antecedente_personal: es el campo que almacena los antecedentes personales del paciente.
Antecedente_familiar: es el campo que almacena los antecedentes familiares del paciente.
Fecha_de_actualizacion: este campo almacena la fecha en que se actualiza la historia clínica.
Numero_documento_paciente: es la llave foránea de la tabla PACIENTE.
70
Tabla 26. Plan_de_Tratamiento.
Descripción: En esta tabla se almacenan la información del tratamiento que se le realiza al paciente.
Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not Null
Numero_tratamiento X Int 4 X
Numero_historia X Double X
Nombre Varchar 40 X
Estado Varchar 12 X
Aprobacion Varchar 2 X
Fecha_inicio Date
Fecha_fin Date
Numero_tratamiento: es la llave primaria de la tabla PLAN_DE_TRATAMIENTO que se encarga de enlazar esta tabla con las demás.
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
Nombre: es el campo que almacena el nombre del tratamiento.
Descripción: es el campo que almacena la descripción del tratamiento odontológico al que se someterá el paciente
Estado: este campo almacena los estados del tratamiento (En Desarrollo, Finalización, Sin Realizar, Aplazado).
Aprobación: este campo almacena la aprobación del paciente a que se le haga el respectivo tratamiento odontológico.
Fecha_inicio: este campo almacena la fecha de inicio del tratamiento.
Fecha_fin: este campo almacena la fecha de finalización del tratamiento.
Anomalías: este campo almacena las anomalías.
71
Tabla 27. Examen_Básico.
Descripción: la tabla almacena la información sobre el examen básico que se le realiza al paciente.
Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not Null
Id_examen X Int 2 X
Nombre Int 40
Numero_historia X Double X
Id_examen: es la llave primaria de la tabla EXAMEN_BASICO que se encarga de enlazar esta tabla con las demás.
Nombre: este campo almacena el nombre del examen que se realizara.
Detalle:
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not Null
Numero_diente X Int 2 X
Cop Varchar 8
Numero_historia X Double X
Numero_diente: es la llave primaria de la tabla DIENTE que se encarga de enlazar esta tabla con las demás.
Cop: cariado, opturado, perdido.
Manifestación: campo que almacena si es blanda o calcificada.
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
72
Tabla 29. Evolución
NOMBRE DE LA TABLA: EVOLUCION.
Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not Null
Fecha X Date X
Hora Time
Valor Int 7
Numero_historia X Double X
Fecha: es la llave primaria de la tabla EVOLUCIÓN que se encarga de enlazar esta tabla con las demás y almacena la fecha en la que se presenta la evolución en el
tratamiento.
Hora: este campo almacena la hora en la cual se realiza el tratamiento.
Descripción: almacena la información de lo que se realizó al paciente y que hace parte del tratamiento.
Valor: es el valor que el paciente cancela por el servicio que se le presta en esa fecha.
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
73
Tabla 30. Anexos.
Descripción: esta tabla almacena la información de los anexos que se adjuntan a los pacientes.
Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not Null
Numero_anexo X Int 3 X
Tipo_anexo Int 15
Numero_historia X Double X
Numero_anexo: es la llave primaria de la tabla ANEXOS que se encarga de enlazar esta tabla con las demás.
tipo_anexo: es el campo que almacena los tipos de anexo, pueden ser imágenes, radiografías, fotos, etc…
Direccion_interna: es el campo que almacena la dirección de la carpeta que contiene los anexos.
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
74
Tabla 31. Citas.
Fecha: Es la llave primaria de la tabla CITAS que se encarga de enlazar esta tabla con las demás. En este campo se almacena la fecha de la cita odontológica.
Hora: En este campo se almacena la hora de la cita odontológica.
Numero_documento_paciente: Es la llave primaria de la tabla PACIENTE. Además es una llave foránea de la tabla CITAS.
Numero_documento_odontólogo: Es la llave primaria de la tabla ODONTÓLOGO. Además es una llave foránea de la tabla CITAS.
Numero_documento_asistente: Es la llave primaria de la tabla ASISTENTE. Además es una llave foránea de la tabla CITAS.
75
Tabla 32. Servicio.
NOMBRE DE LA TABLA: SERVICIO.
Descripción: la tabla almacena la información sobre los servicios que presta el consultorio.
Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not Null
Id_servicio X Int 2 X
Nombre_servicio Varchar 20
Descripcion_de_servicio Text
Id_servicio: es la llave primaria de la tabla SERVICIO que se encarga de enlazar esta tabla con las demás.
Nombre_servicio: es el nombre de los servicios que se prestan en el consultorio.
Descripción_de_servicio: es la descripción de los servicios que se prestan en el consultorio.
Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not Null
Id_servicio_odontologo X Int 2 X
Id_servicio X Int 8 X
Numero_documento_odontologo X Double X
Id_servicio_odontologo: es la llave primaria de la tabla SERVICIO_POR_ODONTOLOGO que se encarga de enlazar esta tabla con las demás.
id_servicio: es la llave foránea de la tabla SERVICIO.
Numero_documento_odontologo: es la llave foránea de la tabla ODONTOLOGO.
76
Tabla 34. SMS.
Id_sms: Es la llave primaria de la tabla SMS que se encarga de enlazar esta tabla con las demás.
Hora_salida_sms: En este campo se almacena la hora de salida del mensaje.
Mensaje_sms: En este campo se almacena el contenido del mensaje.
Estado: En este campo se almacena el estado del mensaje, si el paciente lo recibió o no.
Numero_documento_paciente: Es la llave primaria de la tabla PACIENTE. Además es una llave foránea de la tabla SMS.
77
5.3.2.4.3. Asignación de Privilegios.
USUARIO: ADMINISTRADOR
TABLAS INSERT DELETE UPDATE SELECT
PERSONA X X X
PACIENTE X X X
ACUDIENTE X X X
ASISTENTE X X X
ODONTÓLOGO X X X
ESTUDIO X X X
SERVICIOS_POR_ODONTÓLOGO X X X
SERVICIOS X X X
HISTORIA CLÍNICA X X X
PLAN DE TRATAMIENTO X X X
DIENTE X X X
EXÁMEN BÁSICO X X X
ANEXOS X X X
EVOLUCIÓN X X X
CITAS X X X X
SMS X X X X
USUARIO: ODONTÓLOGO
TABLAS INSERT DELETE UPDATE SELECT
PERSONA X X X
PACIENTE X X X
ACUDIENTE X X X
ASISTENTE
ODONTÓLOGO X X
ESTUDIO X X X
SERVICIOS_POR_ODONTÓLOGO X
SERVICIOS X X
HISTORIA CLÍNICA X X X
PLAN DE TRATAMIENTO X X X
DIENTE X X X
EXÁMEN BÁSICO X X X
ANEXOS X X X
EVOLUCIÓN X X X
CITAS X X X X
SMS
78
Tabla 37. Usuario: Asistente.
USUARIO: ASISTENTE
TABLAS INSERT DELETE UPDATE SELECT
PERSONA X X
PACIENTE
ACUDIENTE
ASISTENTE
ODONTÓLOGO
ESTUDIO
SERVICIOS_POR_ODONTÓLOGO
SERVICIOS
HISTORIA CLÍNICA
PLAN DE TRATAMIENTO
DIENTE
EXÁMEN BÁSICO
ANEXOS
EVOLUCIÓN
CITAS X X X X
SMS X X
USUARIO: PACIENTE
TABLAS INSERT DELETE UPDATE SELECT
PERSONA X X
PACIENTE
ACUDIENTE
ASISTENTE
ODONTÓLOGO
ESTUDIO
SERVICIOS_POR_ODONTÓLOGO
SERVICIOS
HISTORIA CLÍNICA
PLAN DE TRATAMIENTO
DIENTE
EXÁMEN BÁSICO
ANEXOS
EVOLUCIÓN
CITAS X X X X
SMS
79
5.3.2.5. Diseño de las interfaces y el odontograma. Para cumplir con los
requerimientos del aplicativo también se crean las interfaces y el odontograma, los cuales
deben ser amigables en el momento en que los usuarios interactúen con el aplicativo,
puesto que éstas son el medio de comunicación entre los usuarios y el sistema.
La herramienta que se usa para este desarrollo es Dreamweaver, Para esto se hizo en
código HTML (HyperText Markup Language) el cual está plasmado en los JSP’s del
aplicativo, se descargó una plantilla la cual se usa como interfaz para todas las pantallas,
en la parte izquierda se encuentran los links (command Link) que van asociados a
imágenes y los cuales generan una acción determinada.
Para el odontograma, como se muestra en la figura 18, se crea una matriz de las
imágenes de los dientes y se enumeran, para que cada vez que se registra un diente por
medio de la interfaz se refresque la imagen. El bean es el que realiza las consultas y
guarda la información registrada del odontograma a la hora de llenar la historia
odontológica.
80
En el momento de llenar la historia clínica en cada sección se usan determinados
elementos para llenar este registro, por ejemplo en los campos que se deben llenar datos
de usuario se trabaja con un Text-Area como se muestra en la figura 19, en el plan de
tratamiento al escoger los tratamientos a realizar se usan Checkbox como se muestra en
la figura 20, ya que esta función sirve para escoger varios elementos.
En la parte de hábitos de higiene oral se usan Radio Butons que en este caso se emplean
para escoger solo una opción. Para las consultas se usan herramientas de Select One
Menu, que son las listas que aparecen para escoger una opción que se encuentre en
ellas. Por último el uso de botones (command buton) que generan una acción
determinada sobre los beans en algunos casos.
81
Figura 20. Herramientas para el diseño de interfaces.
82
5.4. IMPLEMENTACIÓN Y PRUEBA DE UNIDADES
Las características de hardware con las que se debe contar para la implementación son:
el equipo en el que se desarrolla el código debe tener como mínimo una memoria RAM de
1Gb (Gigabyte) y procesador 1.5 Ghz.
83
Figura 21. Escenario Basado en la Web de J2EE.
84
Figura 22. Conexión Base de Datos.
85
Figura 23. Propiedades de la base de datos.
86
Figura 24. Consulta Personas.
En la figura 25 se hace una consulta para ver las citas que se han programado y están
guardadas en la base de datos.
87
En la figura 26 encontramos a los pacientes que se encuentran registrados en la base de
datos.
88
En la figura 28 podemos encontrar una de las consultas que realiza el asistente por medio
de la interfaz, para saber que citas hay programadas en un día determinado, mostrando el
nombre y el número de documento del paciente, el odontólogo que lo atenderá y la fecha.
89
5.4.1.2. Capa de Negocio. En esta capa se hace el uso de “JavaBeans que son
componentes hechos en software que se pueden reutilizar y que pueden ser manipulado
visualmente por una herramienta de programación en lenguaje Java.”22. Para la
implementación de esta capa se crean los siguientes JavaBeans como se muestran en la
figura 29, que son necesarios para ofrecer los servicios con los que éste debe contar.
Estos beans son los siguientes: ActualizaPaciente, Anexos, Evolucion, Historial,
IngresarEstudio, PlandeTratamiento, InsertarAcudiente, Registro, Odontograma,
Servicios, AsignarCita, ConsultarCitas, SolicitarCita, SesionAsistente, SesionOdontologo,
SesionPaciente, InicioAsistente, InicioPaciente e InicioOdontologo. Los beans antes
mencionados se clasifican de la siguiente manera:
22
Definición JavaBean [artículo en línea] Disponible desde Internet en:
<http://www.sc.ehu.es/sbweb/fisica/cursoJava/applets/javaBeans/fundamento.htm#Definición de JavaBean>, Octubre 5
de 2010, 2:23 p.m.
90
Figura 29. JavaBeans de la aplicación.
En esta capa también se encuentra el proceso que se lleva a cabo para implementar la
mensajería de texto a través de un servicio llamado elibom, el cual ofrece un ejemplo del
código en java, el cual conecta la aplicación al Gateway de mensajería para enviar
mensajes SMS de forma automática. En la figura 30 se muestra el código que se
implementó en la aplicación para le envió de mensajes SMS.
91
Figura 30. Código para envió de SMS.
Para usar este servicio antes debe hacerse un registro de usuario por medio de la página
www.elibom.com para que se pueda usar el mail, contraseña (del registro), número de
celular y mensaje que se va a enviar.
5.4.1.3. Capa Web. “Se encuentra en el servidor web y contiene la lógica de presentación
que se utiliza para generar una respuesta al cliente. Recibe los datos del usuario desde la
capa cliente y basado en estos genera una respuesta apropiada a la solicitud. J2EE utiliza
en esta capa los componentes Java Servlets y JavaServer Pages para crear los datos que
se envían al cliente”.23. En la figura 31 se encuentran los JSP implementados en esta
capa para desplegar las páginas con las que cuenta la aplicación, a continuación se
mencionan algunos JSP’s que se encuentran:
23
Investigación de la plataforma J2EE y su aplicación práctica [artículo en línea] Disponible desde Internet en:
<http://www.dcc.uchile.cl/~jbarrios/jbarrios@dcc.uchile.cl>, Octubre 7 de 2010, 4:01 p.m.
92
JSP’s para actualizar datos de los usuarios.
93
Figura 31. JSP´s de la aplicación.
El código XML nombra los beans para realizar las acciones determinadas por cada uno y
también a los JSP´s para encadenar cada página y crear las reglas de navegación. Este
código se encuentra en la aplicación en la parte de Configuration Files, faces-config.xml,
en la herramienta de desarrollo en netbeans.
5.4.1.4. Capa Cliente. Es la interfaz gráfica del sistema y se encarga en interactuar con
el usuario. La figura 32 es la interfaz del aplicativo que sirve para que un paciente se
pueda registrar por medio de la página web. Las demás interfaces se encuentran en el
manual de usuario, ya que con ellas se explica paso a paso el funcionamiento del
aplicativo.
94
Figura 32. Interfaz Gráfica del Aplicativo.
5.4.2. Prueba de Unidades. En esta etapa del proyecto se llevan a cabo las pruebas a
cada uno de los módulos, se ejecutan y si fallan se procede a localizar el fallo y repararlo.
“Pueden aplicarse cuando aún no esté implementado el código fuente del programa, pero
sí se conoce lo que se espera que haga”.25
24
Pruebas del sistema, [artículo en línea] Disponible desde Internet en:
<http://www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/testing.htm>, Octubre 6 de 2010, 10:34 a.m.
25
TUYA Javier, RAMOS ROMAN Isabel, DOLADO COSIN Javier, Técnicas Cuantitativas Para La Gestión En La
Ingeniería del Software, Editores NETBIBLO, España 2007, p 49.
95
5.4.2.1. Prueba Autenticación. Se realizan las pruebas de autenticación para el paciente,
odontólogo, asistente y administrador; los cuales interactúan todo el tiempo con el sistema
y están representadas en las tablas 39 y 40.
Objetivo: Probar la acción de iniciar sesión del paciente, odontólogo, asistente y administrador cuando sus datos están en
la base de datos.
Salidas deseadas: Los usuarios inician sesión correctamente y pueden hacer uso de los servicios a los que puede
acceder.
Objetivo: Probar la acción de cerrar sesión del paciente, odontólogo, asistente y administrador cuando ha iniciado una
sesión.
Condiciones de la prueba: Los usuarios deben estar registrados con anterioridad y haber iniciado la sesión.
Salidas deseadas: Los usuarios cierran sesión correctamente y vuelven a la página principal.
5.4.2.2. Prueba Registrar Usuario. Se realizan las pruebas a los registros de los
pacientes que se hacen por medio de la página web, los demás usuarios del sistema
deben ser registrados por el administrador, se describe esta prueba en la tabla 41.
96
Condiciones de la prueba: Los usuarios deben ingresar los datos requeridos para su registro.
Entradas: Nombre, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento,
ocupación, dirección, barrio, teléfono y celular.
5.4.2.3. Pruebas Actualizar Usuario. Para actualizar los datos de los usuarios
previamente deben estar autenticados como lo muestra la tabla 42.
Condiciones de la prueba: Los usuarios deben estar registrados y autenticados con anterioridad, solo se pueden
actualizar los campos permitidos.
97
Tabla 44. Caso de Prueba Consultar Historia Clínica Odontológica.
5.4.2.5. Prueba Citas. Para realizar estas pruebas los usuarios deben estar autenticados
con anterioridad en el sistema, en este módulo se pueden solicitar y cancelar citas que
corresponden a las tablas 45 y 46 respectivamente.
Condiciones de la prueba: Los usuarios deben estar autenticados con anterioridad. Cuando el usuario ingrese los datos
requeridos se confirma la disponibilidad para crear la cita.
Entradas: Número de documento del paciente, día, fecha, hora de la cita, y odontólogo disponible.
98
5.4.2.6. Prueba Enviar Sms. Después que la asistente se autentica procederá a enviar el
sms al celular del paciente indicando la fecha y hora de su próxima cita odontológica
como se muestra en la tabla 47.
Objetivo: Probar la acción de enviar un mensaje de texto al celular de los pacientes para recordar la fecha y hora de la
próxima cita odontológica.
Condiciones de la prueba: La asistente debe estar autenticada con anterioridad y la información del paciente debe estar
en la base de datos.
99
En la figura 34 se muestra en la base de datos que el mensaje de texto corto ha sido
enviado con éxito a su destinatario.
100
5.5. INTEGRACIÓN Y PRUEBAS DEL SISTEMA.
Seguido de las pruebas funcionales se procede a realizar las pruebas del sistema en
conjunto, esto se hace para determinar si se cumplen con los requerimientos, identificar y
corregir los errores que se pueden presentar en el funcionamiento del aplicativo. Todas
las pruebas que a continuación se describen en las tablas 48, 49, 50 y 51 se han hecho a
través de la interfaz creada para la comunicación entre el usuario y el sistema.
Entradas: Nombre, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento,
ocupación dirección barrio teléfono celular.
101
Figura 35. Error Registro.
Objetivo: Probar la acción de registrar un usuario con datos que no son válidos.
Entradas: Nombre, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento,
ocupación, dirección, barrio, teléfono, celular no válidos.
Se identifica que el sistema hace el registro sin enviar ningún mensaje de error, pero no
guarda ese registro en la base de datos.
102
Se corrige el error validando que cada uno de los campos que se ingresan son los
correctos y realiza el registro, en caso contrario envía un mensaje diciendo que
compruebe los datos ingresados.
Entradas: ninguna.
Se corrige la prueba mostrando todas las salidas deseadas como se ve en la figura 36.
103
Tabla 51. Autenticar usuarios con datos no válidos.
104
5.6. FUNCIONAMIENTO Y MANTENIMIENTO
Esta fase no se realizó, porque, no es inmediata sino que hace parte de un proceso de
acompañamiento a mediano plazo, en el cual se debe tener disponibilidad para solucionar
problemas e imprevistos que se generan en el uso del software, mientras la persona que
lo utiliza en lo cotidiano se capacita totalmente.
105
6. PRESENTACIÓN Y ANÁLISIS DE RESULTADOS
Para alcanzar los objetivos propuestos se desarrollaron con éxito cada una de las etapas
establecidas en la metodología del modelo en cascada y se presentan los siguientes
resultados:
Igualmente la mayoría de los encuestados coincidieron en que para ellos sería más
cómodo, rápido y fácil solicitar o cancelar su próxima cita odontológica por medio de una
página web, ya que en ella se pueden visualizar horarios, fechas y odontólogos
disponibles con su respectiva especialidad.
106
Diseño del sistema
En la fase de pruebas de unidades se realizaron las pruebas de caja negra las cuales se
centran en lo que se espera de cada uno de los módulos implementados, se ejecutó cada
uno de ellos y en el momento que se encontraron fallos se procedió a localizarlos y
repararlos.
107
Integración y pruebas del sistema.
Funcionamiento y mantenimiento
108
CONCLUSIONES
Las pruebas permitieron detectar los errores y fallas identificadas a lo largo del desarrollo
del proyecto; a partir de estas se corrigieron para hacer entrega de un software que
cumple con los requerimientos planteados.
109
RECOMENDACIONES
Incluir los temas que abarcan la plataforma J2EE en las materias que son electivas para
el programa de ingeniería de sistemas, ya que está presente en las nuevas tecnologías y
actualmente no se encuentra mucha información acerca de cómo hacer uso de ella.
El buen modelamiento de la base de datos debe reflejar todas las entidades y atributos
imprescindibles para que se puedan guardar los datos, éste es uno de los pasos más
tediosos para la realización de una aplicación que interactúe con ésta, ya que si no es
bien modelada se puede tardar más del tiempo estimado para la culminación del proyecto.
Cumplir con todas las etapas de manera secuencial establecidas en la metodología que
se escoja, puesto que en cada una de ellas se pueden solucionar los inconvenientes que
se presenten en el momento y así no tener dificultades graves con el producto final.
Adquirir un servicio de hosting que soporte el motor de bases de datos MySql, el servidor
de aplicaciones Apache Tomcat y el lenguaje java para usar el aplicativo en la web.
110
BIBLIOGRAFÍA
DEBRAUER, LAUREN Y VAN DER HEIDE, FIEN UML2, Ediciones ENI. Barcelona 2009.
245 p.
DEITEL, Harvey y Deitel Paul. Como Programar en Java. México: Pearson Prentice Hall,
2004. 1268 p.
PRESSMAN S. Roger. Ingeniería del software un enfoque práctico. México: Mc Graw Hill,
2006. 958 p.
RODRIGUEZ ALMEIDA, Miguel Ángel. Bases de Datos, Mc. Graw Hill. P257.
SOMMERVILLE, Ian. Ingeniería del software. Madrid: Pearson Educación. S.A., 2005.
712 p.
TUYA Javier, RAMOS ROMAN Isabel, DOLADO COSIN Javier, Técnicas Cuantitativas
Para La Gestión En La Ingeniería del Software, Editores NETBIBLO, España 2007, 325 p.
111
WEITZENFELD, Alfredo. Ingeniería de software orientada a objetos con Uml. Java e
internet. México: Thomson, 2005. 678 p.
112
WEBGRAFÍA
113
Definición de Ingeniería de software, metodologías y ciclos de vida, [artículo en línea]
Disponible desde Internet en: < http://www.slideshare.net/vdaniel20/metodologas-y-ciclos-
de-vida > [con acceso el 31 de julio de 2010]
Análisis y Diseño Orientado a Objetos, [artículo en línea] Disponible desde Internet en:
<http://www.dcc.uchile.cl/~luguerre/cc40b/clase13.html> [con acceso el 8 de agosto de
2010]
Ejemplo para el manejo de una historia clínica odontológica, [artículo en línea] Disponible
desde Internet en:
http://www.saludcapital.gov.co/Publicaciones/Garantia%20de%20Calidad/GUIA%20PRAC
TICA%20DE%20HABILITACION/Anexos%20Guia%20Practica%20ajustados/Anexo%20N
%C2%B0%2037%20Protocolo%20de%20Uso%20y%20Manejo%20Historia%20Clinica.do
c, [Con acceso Agosto 5 de 2010]
114
GLOSARIO ODONTOLÓGICO
CIRUGÍA: tiene por objeto tratar las enfermedades de los dientes y de los maxilares.
SELLANTE: resina fluida que se utiliza para sellar las fosas y fisuras de los dientes
jóvenes para prevenir la caries dental.
115
GLOSARIO TÉCNICO
J2EE: Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2
Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de
programación—parte de la Plataforma Java—para desarrollar y ejecutar software de
aplicaciones en Lenguaje de programación Java con arquitectura de N niveles distribuida,
basándose ampliamente en componentes de software modulares ejecutándose sobre un
servidor de aplicaciones.
JSP: JavaServer Pages (JSP) es una tecnología Java que permite generar contenido
dinámico para web, en forma de documentos HTML, XML o de otro tipo. Ésta tecnología
es un desarrollo de la compañía Sun Microsystems. La Especificación JSP 1.2 fue la
primera que se liberó y en la actualidad está disponible la Especificación JSP 2.1.
XML: Extensible Markup Language (XML) es un sencillo, formato de texto muy flexible
derivado de SGML (ISO 8879). Originally designed to meet the challenges of large-scale
electronic publishing, XML is also playing an increasingly important role in the exchange of
a wide variety of data on the Web and elsewhere. Originalmente diseñado para afrontar
los retos de gran escala de la publicación electrónica, XML también está desempeñando
un papel cada vez más importante en el intercambio de una amplia variedad de datos en
la Web y en otros lugares.
116
ANEXO A.
Ejemplo de procedimiento institucional documentado para el uso y manejo de la
historia clínica de un servicio odontológico
ANEXO A. XXXXXXXXXXXXXXXXX
INSTITUCION
FECHA DE
DD/MM/AAAA
ACTUALIZACIÓN:
CONTENIDO
1. Definición
2. Normatividad vigente
3. Directivas internas sobre la Historia Clínica
3.1 Historia Clínica Única
3.2 Obligatoriedad de la apertura de Historia Clínica
3.3 Obligatoriedad del registro
3.4 Calidad de los registros en la Historia Clínica
3.5 Custodia de la Historia Clínica
4. Características de la Historia Clínica
5. Componentes de la Historia Clínica
6. Formatos de la Historia Clínica
6.1 Historia Clínica (Apertura de Historia Clínica de Primera Vez)
6.2 Evolución del Tratamiento
6.3 Referencia y Contrarreferencia
6.4 Consentimiento Informado
6.5 Presupuesto Odontológico
7. Instructivos de la Historia Clínica
8. Diligenciamiento de la Historia Clínica
9. Uso de la Historia Clínica
10. Manejo de la Historia Clínica
10.1 Archivo de Historias Clínicas
10.2 Registro de salida y entrada de Historias Clínicas
10.3 Foliación de Historias Clínicas
10.4 Registro general de Historias Clínicas
11. Anexos específicos de la Historia Clínica
117
1. DEFINICIÓN.
118
2. NORMATIVIDAD VIGENTE
Calidad de los registros en la Historia Clínica: “La Historia Clínica debe diligenciarse
en forma clara, legible, sin tachones, enmendaduras, intercalaciones, sin dejar espacios
en blanco y sin utilizar siglas. Cada anotación debe llevar la fecha y hora en la que se
realiza, con el nombre completo y firma del autor de la misma”.
119
Custodia de la Historia Clínica: Aunque en este Protocolo se establecen los flujos y
manejos de entrada y salida de la Historia Clínica del archivo y las personas responsables
de los mismos, debido al carácter confidencial y de reserva de la Historia Clínica, todo el
personal asistencial y administrativo de la institución relacionado con el manejo y tráfico
de la Historia Clínica debe velar por su custodia y conservación.
120
El documento de Apertura de Historia Clínica de Primera Vez, de donde
se registran los datos de identificación del paciente, la anamnesis y la
información clínica resultante de la atención de Primera vez, y
La Historia Clínica como el expediente que incluye el documento de
apertura mencionado arriba y todos los demás documentos de la Historia
Clínica.
122
Historia Clínica (Apertura de Historia Clínica de Primera Vez)
Evolución del Tratamiento
Referencia y Contrarreferencia
Consentimiento Informado
Presupuesto Odontológico
123
se restringe única y exclusivamente al personal asistencial odontológico de XXXXXX, y,
en aspectos restringidos únicamente al traslado, archivo y procesos de actualización y
conservación, al personal administrativo no asistencial quien deberá guardar la misma
reserva y confidencialidad de la Historia Clínica que el personal asistencial. Tales
procesos administrativos se refieren en general a: archivo ordenado, registro de entradas
y salidas del mismo, foliada de hojas, organización en carpetas, marcación de carpetas,
distribución a los consultorios y transporte interno en XXXXXXX.
124
Foliación de Historias Clínicas. Las Historias Clínicas serán foliadas con números
arábigos consecutivos comenzando por la primera hoja diligenciada y continuando en
orden secuencial cronológico con las hojas subsiguientes.
Firma de aprobación:
_________________________________________________________
125
ANEXO B.
Formato Historia Clínica Odontológica
126
127
ANEXO C.
Resolución Número 1995 de 1999 (Julio 8)
MINISTERIO DE SALUD
(JULIO 8)
EL MINISTRO DE SALUD
En ejercicio de las facultades legales y en especial las conferidas por los artículos 1, 3, 4 y
los numerales 1 y 3 del artículo 7 del Decreto 1292 de 1994 y CONSIDERANDO
Que la Ley 100 de 1993, en su Artículo 173 numeral 2, faculta al Ministerio de Salud para
dictar las normas científicas que regulan la calidad de los servicios, de obligatorio
cumplimiento por parte de todas las Entidades Promotoras de Salud, los Prestadores de
Servicios de Salud del Sistema General de Seguridad Social en Salud y las direcciones
Seccionales, Distritales y Locales de Salud.
CAPÍTULO I
b) Estado de salud: El estado de salud del paciente se registra en los datos e informes
acerca de la condición somática, psíquica, social, cultural, económica y medioambiental
que pueden incidir en la salud del usuario.
c) Equipo de Salud. Son los Profesionales, Técnicos y Auxiliares del área de la salud que
realizan la atención clínico asistencial directa del Usuario y los Auditores Médicos de
Aseguradoras y Prestadores responsables de la evaluación de la calidad del servicio
brindado.
e) Archivo de Gestión: Es aquel donde reposan las Historias Clínicas de los Usuarios
activos y de los que no han utilizado el servicio durante los cinco años siguientes a la
última atención.
129
f) Archivo Central: Es aquel donde reposan las Historias Clínicas de los Usuarios que no
volvieron a usar los servicios de atención en salud del prestador, transcurridos 5 años
desde la última atención.
e) Archivo Histórico. Es aquel al cual se transfieren las Historias Clínicas que por su valor
científico, histórico o cultural, deben ser conservadas permanentemente.
CAPÍTULO II
DILIGENCIAMIENTO
Todo prestador de servicios de salud que atiende por primera vez a un usuario debe
realizar el proceso de apertura de historia clínica.
A partir del primero de enero del año 2000, la identificación de la historia clínica se hará
con el número de la cédula de ciudadanía para los mayores de edad; el número de la
tarjeta de identidad para los menores de edad mayores de siete años, y el número del
registro civil para los menores de siete años. Para los extranjeros con el número de
pasaporte o cédula de extranjería. En el caso en que no exista documento de identidad de
los menores de edad, se utilizará el número de la cédula de ciudadanía de la madre, o el
del padre en ausencia de ésta, seguido de un número consecutivo de acuerdo al número
de orden del menor en el grupo familiar.
131
PARÁGRAFO PRIMERO. Mientras se cumple el plazo en mención, los prestadores de
servicios de salud deben iniciar el proceso de adecuación correspondiente a lo ordenado
en el presente artículo.
PARÁGRAFO SEGUNDO. Todo prestador de servicios de salud debe utilizar una historia
única institucional, la cual debe estar ubicada en el archivo respectivo de acuerdo a los
tiempos de retención, y organizar un sistema que le permita saber en todo momento, en
qué lugar de la institución se encuentra la historia clínica, y a quien y en qué fecha ha sido
entregada.
Todos los folios que componen la historia clínica deben numerarse en forma consecutiva,
por tipos de registro, por el responsable del diligenciamiento de la misma.
Los contenidos mínimos de este componente son: datos personales de identificación del
usuario, apellidos y nombres completos, estado civil, documento de identidad, fecha de
nacimiento, edad, sexo, ocupación, dirección y teléfono del domicilio y lugar de residencia,
nombre y teléfono del acompañante; nombre, teléfono y parentesco de la persona
responsable del usuario, según el caso; aseguradora y tipo de vinculación.
132
julio 2 de 1998 y las normas que la modifiquen o adicionen y los generalmente aceptados
en la práctica de las disciplinas del área de la salud.
Son todos aquellos documentos que sirven como sustento legal, técnico, científico y/o
administrativo de las acciones realizadas al usuario en los procesos de atención, tales
como: autorizaciones para intervenciones quirúrgicas (consentimiento informado),
procedimientos, autorización para necropsia, declaración de retiro voluntario y demás
documentos que las instituciones prestadoras consideren pertinentes.
CAPÍTULO III
Todos los prestadores de servicios de salud, deben tener un archivo único de historias
clínicas en las etapas de archivo de gestión, central e histórico, el cual será organizado y
prestará los servicios pertinentes guardando los principios generales establecidos en el
Acuerdo 07 de 1994, referente al Reglamento General de Archivos, expedido por el
Archivo General de la Nación y demás normas que lo modifiquen o adicionen.
La custodia de la historia clínica estará a cargo del prestador de servicios de salud que la
generó en el curso de la atención, cumpliendo los procedimientos de archivo señalados
en la presente resolución, sin perjuicio de los señalados en otras normas legales vigentes.
El prestador podrá entregar copia de la historia clínica al usuario o a su representante
legal cuando este lo solicite, para los efectos previstos en las disposiciones legales
vigentes.
134
PARÁGRAFO SEGUNDO. En los eventos en que existan múltiples historias clínicas, el
prestador que requiera información contenida en ellas, podrá solicitar copia al prestador a
cargo de las mismas, previa autorización del usuario o su representante legal.
1) El usuario.
2) El Equipo de Salud.
La historia clínica debe conservarse por un periodo mínimo de 20 años contados a partir
de la fecha de la última atención. Mínimo cinco (5) años en el archivo de gestión del
prestador de servicios de salud, y mínimo quince (15) años en el archivo central.
135
ARTÍCULO 16.- SEGURIDAD DEL ARCHIVO DE HISTORIAS CLÍNICAS.
Los Prestadores de Servicios de Salud pueden utilizar medios físicos o técnicos como
computadoras y medios magneto-ópticos, cuando así lo consideren conveniente,
atendiendo lo establecido en la circular 2 de 1997 expedida por el Archivo General de la
Nación, o las normas que la modifiquen o adicionen.
Los programas automatizados que se diseñen y utilicen para el manejo de las Historias
Clínicas, así como sus equipos y soportes documentales, deben estar provistos de
mecanismos de seguridad, que imposibiliten la incorporación de modificaciones a la
Historia Clínica una vez se registren y guarden los datos.
En todo caso debe protegerse la reserva de la historia clínica mediante mecanismos que
impidan el acceso de personal no autorizado para conocerla y adoptar las medidas
tendientes a evitar la destrucción de los registros en forma accidental o provocada.
136
Los prestadores de servicios de salud deben permitir la identificación del personal
responsable de los datos consignados, mediante códigos, indicadores u otros medios que
reemplacen la firma y sello de las historias en medios físicos, de forma que se establezca
con exactitud quien realizó los registros, la hora y fecha del registro.
CAPÍTULO IV
PARÁGRAFO. El comité debe estar integrado por personal del equipo de salud. De las
reuniones, se levantarán actas con copia a la dirección de la Institución.
137
ARTICULO 21. - SANCIONES.
Ministro de Salud
138
ANEXO D.
Encuesta pacientes
139
8. ¿Está conforme con el proceso que se lleva actualmente en el consultorio odontológico
para pedir su próxima cita?
9. ¿Cree que si pudiera agendar su próxima cita odontológica por medio de una página
en internet sería más como y rápido? ¿Por qué?
10. ¿Para el proceso de registrarse como paciente nuevo cree que es necesario una foto
para almacenar en su registro?
11. ¿Los horarios y los días de atención que maneja el consultorio son adecuados para
usted como paciente?
12. ¿Le gustaría que le recordaran con un mensaje de texto a su celular la fecha y hora
de su próxima cita?
13. ¿Le gustaría que al usar la página web del consultorio pueda consultar los horarios,
fechas y odontólogos disponibles a los cuales usted desee acudir?
140
14. ¿Cuándo no puede acudir a una cita en que forma la cancela?
15. ¿Para su comodidad desearía que se puedan cancelar citas por medio de la página
web del consultorio?
16. ¿Si necesitan actualizar sus datos tiene que acudir al consultorio? ¿De qué otra
forma lo hace?
17. ¿Le parecería buena la opción de actualizar sus datos por medio de la página web
del consultorio en vez de usar los métodos que anteriormente menciono?
141
ANEXO E.
Resultados de las encuestas
Al término del desarrollo de las etapas de este proyecto se presenta un análisis sobre la
información obtenida por medio de las encuestas realizadas.
Para generar el análisis a estos resultados se agruparon las preguntas de tal manera que
las respuestas se lograran combinar en una misma gráfica.
En la gráfica 2 se muestra que para la pregunta 3 todos los pacientes encuestados cada
vez que piden una cita lo hacen de manera telefónica. En la pregunta 4 casi siempre hay
alguna manera que a los pacientes se les recuerda su próxima cita.
143
Gráfica 3. Resultados Encuesta – Preguntas 8, 9, 10 y 11.
12. ¿Le gustaría que le recordaran con un mensaje de texto a su celular la fecha y hora
de su próxima cita?
13. ¿Le gustaría que al usar la página web del consultorio pueda consultar los horarios,
fechas y odontólogos disponibles a los cuales usted desee acudir?
15. ¿Para su comodidad desearía que se puedan cancelar citas por medio de la página
web del consultorio?
16. ¿Si necesitan actualizar sus datos tiene que acudir al consultorio? ¿De qué otra
forma lo hace?
17. ¿Le parecería buena la opción de actualizar sus datos por medio de la página web
del consultorio en vez de usar los métodos que anteriormente mencionó?
144
Gráfica 4. Resultados Encuesta – Preguntas 12, 13, 15, 16 y 17.
145
ANEXO F.
Ficha técnica y resultados encuestas
146
ANEXO G.
Entrevista Odontóloga
15 años.
No.
147
7. ¿Cuál es el proceso que llevan a cabo desde el momento en que un paciente
solicite su cita?
9. ¿Se crea historia clínica para todos los pacientes que visitan el consultorio?
Ninguna.
148
Una solo ella.
15. ¿Cómo se cancelan las citas en caso de que el paciente no pueda asistir?
No ninguna.
30 minutos.
No ningún convenio.
20. ¿Qué opina del sistema que utilizan actualmente para el manejo de las historias
clínicas?
22. ¿Cuáles son las características con las cuales debería contar la aplicación?
149
Fácil de aprender y usar, que muestre la información de forma clara y que no
sea tedioso el aprendizaje de funcionamiento de la aplicación.
150
FECHA 25-11-2010
NÚMERO RAE
AUTOR (ES)
151
una manera eficiente y versátil.
152
Software, Editores NETBIBLO, España 2007, 325 p.
153
NÚMERO RAE
CONTENIDOS
OBJETIVOS
Objetivos Específicos.
154
Alcances. El proyecto culmina con la implementación de la
aplicación web y con las pruebas aceptación que se realizarán
para determinar si esta cumple con los requerimientos
especificados.
NÚMERO RAE
155
METODOLOGÍA
ENFOQUE DE LA INVESTIGACIÓN
156
CONCLUSIONES Los requerimientos obtenidos son la base para empezar a
construir el software de acuerdo a las necesidades del usuario
final, estos ayudan a establecer las entradas, procesos y salidas
que el aplicativo debe generar para su buen funcionamiento.
157
estas se corrigieron para hacer entrega de un software que
cumple con los requerimientos planteados.
158