TABLA DE CONTENIDO

INTRODUCCIN 4

DESCRIPCIN DEL SISTEMA 5

FASE INICIO 13

Captulo 1: Requerimientos 13 1.1. Documento Visin 13 1.2. Plan de Desarrollo del Software 13 1.3. Arquitectura del Software 13 1.4. Glosario de Trminos 14 1.5. Lista de Riesgos 14 Captulo 2: Modelo Del Negocio 14 2.1 Modelo de Casos de Uso del Negocio (MCUN) 14 2.2 Especificacin del Caso de Uso del Negocio (ECUN) 15 2.3 Diagrama de Actividades del Proceso del Negocio (PN) 15 2.4 Modelo de Objetos del Negocio (MON) 15 Captulo 3: Captura de Requerimientos 15 3.1 Modelo Conceptual o Lgico 15 3.2 Modelo de casos de Uso (MCU) 16

FASE ELABORACIN 17

Captulo 4: Anlisis O.O 17 4.1 Anlisis de la Arquitectura 17 4.2. Analizar un Caso de Uso 23

4.3. Realizaciones de los Casos de Uso de Anlisis 28 CAPTULO 5 : DISEO O.O ORIENTADO A LA WEB 29 5.1.1 Modelo de diseo 29 5.1.2 Identificar Tcnicas de diseo 29 5.1.3. Diseo de Casos de Uso 42 5.1.4. Realizaciones de casos de uso en la Web 42 5.1.2 Diagrama de Clases de Diseo 43 5.1.3 Modelo de Persistencia 47 5.1.4 Script 47 CAPITULO 6 : MODELO DE IMPLEMENTACIN 48 6.1.1.Diagrama de Paquetes 48 6.1.2.Diagrama de Componentes 48 6.1.4. Diagrama de Distribucin (considerando la WEB) 49

FASE DE CONSTRUCCIN 51

CAPTULO 7 : CODIFICACIN 51 7.1.1 Instalacin y configuracin de Apache, Tomcat y Eclipse Error! Marcador no definido. 7.1.2. Interfase grfica del Usuario (GUI) 60 7.1.3. Codificacin Orientada a Objetos Error! Marcador no definido. 7.1.4. Estructura de Base de Datos 61 7.1.5. Conexin del Software con la Base de Datos 62 CAPTULO 8 : MODELO DE PRUEBAS 63 8.1.2. Preparacin de un Caso de Prueba 66

CONCLUSIONES 67

RECOMENDACIONES 69

BIBLIOGRAFA 70

ANEXOS 72

Anexo 1: Visin SCCOA 73 Anexo 2: Plan de Desarrollo de Software 90 Anexo 3: Arquitectura de Software 107 Anexo 4: Glosario 119 Anexo 5: Lista de Riesgos 126 Anexo 6: Modelo de Caso de Uso de Negocio 131 Anexo 7: Especificacin de Casos de Uso de Negocio 133 Anexo 8: Modelo de Objetos de Negocio 155 Anexo 9: Modelo Conceptual y Lgico 157 Anexo 10: Priorizacin de los Casos de Uso 160 Anexo 11: Modelo Casos de Uso del Sistema 165 Anexo 12: Especificaciones de Caso de Uso 167 Anexo 13: Especificaciones de Realizaciones de Caso de Uso Anlisis 210 SCCOA 215 Anexo 14: Prototipos de Interfaz Grfica de Usuario 260 Anexo 15: Mapas de Navegacin 278 Anexo 16 : Especificacin de la Realizacin de caso de uso de diseo 299 Anexo 17 : Modelo de Persistencia 330 Anexo 18 : Realizaciones de casos de uso en la Web 332 Anexo 19 : Script 333 Anexo 20 : Caso de Pruebas 339

INTRODUCCIN

El presente proyecto de software se realizara con el fin de ampliar nuestros conocimientos en Ingeniera de Software. Utilizamos como herramienta principal para desarrollo de nuestro trabajo la metodologa RUP (Rational Unified Process) y el lenguaje de modelamiento estndar UML.

El RUP provee un enfoque disciplinado para garantizar tareas y responsabilidades. RUP utiliza UML para especificar, visualizar, construir y documentar componentes de sistemas de software.

El Proyecto en estudio es Sistema de Control de Citas Oftalmolgica Asmat. Para levantar informacin y obtener el anlisis de requerimientos durante la Fase de Inicio, se han realizado varias visitas a la Clnica Oftalmolgica. Actualmente se est programando otra visita para la aprobacin de los prototipos.

DESCRIPCIN DEL SISTEMA

RESUMEN EJECUTIVO

Idea de Negocio

El presente proyecto establece la creacin de un Sistema para el Control de citas de la Oftalmolgica Asmat, cuya finalidad principal es llegar a satisfacer todos los requerimientos impuestos por usuarios y clientes, logrando as construir un sistema que sea amigable, eficiente, rpido y fcil de usarlo.

La estrategia propuesta requiere del diseo e implantacin de aplicaciones

informticas, que permita sustituir al actual sistema, para brindar mejores resultados a la oftalmolgica, disminuyendo el tiempo de la realizacin de sus procesos.

Equipo directivo y promotores del negocio

El grupo de desarrollo GIC, esta orientado al diseo y construccin de aplicaciones informticas de la ms alta calidad. Somos un grupo desarrollador nuevo en el mercado pero a la vez con prestigio y garanta comprobada por nuestros clientes. El jefe del proyecto la Srta. Morales y la persona que nos facilita el acceso a la informacin dentro de la Oftalmolgica Asmat es el Presidente de Directorio Dr. Cirujano Oftalmlogo Miguel Humberto Asmat Urea.

Estado de desarrollo del negocio

Hemos realizado el Modelo del Negocio, Requerimientos, Anlisis y estamos realizando el Diseo en su fase de elaboracin.

Productos/ servicios

Desarrollamos software a medida basndonos en la metodologa RUP, utilizando la notacin UML. Adems entregamos el software en el tiempo y plazo requerido de acuerdo al Plan de Desarrollo de Software, adjuntando toda la documentacin requerida. Adicionalmente brindamos capacitacin al usuario para el uso adecuado del sistema. El proyecto que vamos a desarrollar est dirigido a los pacientes, personal mdico,

personal administrativo y gerentes de la oftalmolgica; Quienes Consultan horarios, ingresan y modifican data, generan reportes, conciertan citas y supervisan procesos.

Pblico objetivo

Los sistemas que desarrollamos estn dirigidos a todo tipo de empresas que requieran integrar sus procesos y adecuarlos a la tecnologa actual.

DESCRIPCIN DEL SISTEMA

RESUMEN

Sistema de Control de Citas Oftalmolgica Asmat al cual, desde este momento denominaremos SCCOA, es un producto de software que permite eficaz control de citas reduciendo tiempos de espera a travs de fcil y confiable ingreso y acceso a datos adems de contar con informacin en lnea mediante el cual los pacientes puedan consultar y verificar sus horarios de citas, que permite eficaz control de citas reduciendo tiempos de espera a travs de fcil y confiable ingreso y acceso a datos adems de contar con informacin en lnea mediante el cual los pacientes puedan consultar y verificar sus horarios de citas.

INTRODUCCIN

El problema actual del sistema es que no posee una base de datos consistente con el sistema actual, la poca eficacia y lentitud del proceso de control de citas, no tiene un backup de seguridad, no hay un sistema de apoyo ni un plan de contingencia; esto afecta a

los pacientes, secretarias, doctores y administrativos. El impacto de este son los gastos innecesarios, tiempo de proceso mayor del requerido y los grandes perjuicios a los pacientes, secretarias y administradores.

La solucin propuesta es una base de datos confiable y segura, acceso y recopilacin de la informacin de manera fcil, rpida y confiable, que sea compatible con otros sistemas, un back up de seguridad, realizar cambios sin afectar el sistema, interfase Grfica de Usuario personalizada, es decir diseada de acuerdo a lo que el operador requiere. Consultas va Internet para verificar citas por los pacientes.

DESCRIPCIN

Registrar Cita

El paciente solicita una cita. Si es el paciente es nuevo se le registra en el sistema creando la ficha clnica la cual contendr los siguientes datos:

_Fecha de registro

_No de Historia

_Datos personales:

Apellido Paterno Apellido Materno Nombres Fecha de Nacimiento

 Edad Documento de identidad Estado Civil Nro. De Telfono Direccin Distrito Provincia Direccin de correo electrnico

_Datos Familiares

Nombres Apellidos Parentesco Domicilio Referido Documento de identidad Nmero Telefnico Direccin

_Motivo y las indicaciones mdicas, las cuales tambin se incluirn en el sistema y se podr ver la evolucin de la ficha clnica electrnica.

En el sistema actual en la ficha electrnica no estn los datos de mail. Todos los datos y las citas se registran en una agenda manualmente y luego se pasan al sistema, a este proceso se le denomina vaciar citas.

Asignar Horario de Cita

Una vez identificado el paciente se selecciona el horario y fecha de la cita, se le asigna doctor, dependiendo del horario del mdico, del paciente y tipo de cita (examen, ciruga o consulta)

La Oftalmolgica Asmat se distingue por su atencin personalizada y exclusiva, por ello es el paciente quin elige al doctor que lo va a atender.

En caso ocurran incidentes como modificacin o cancelacin de citas se realizan en el sistema.

Consultar Cita La Secretaria podr verificar las citas hechas por los pacientes. Esta consulta podr ser realizada en cualquier momento. Permitir tener conocimiento del no. de pacientes que se atendern o se atendieron en el da.

En el sistema actual la secretaria consulta citas y las imprime para el doctor y personal de seguridad. En el sistema a realizar la secretaria y administrador tendrn acceso limitado al sistema de acuerdo a las funciones que desempean. El usuario podr acceder al sistema desde cualquier ubicacin en la que se encuentre, debido a que el sistema ser va Web.

Verificar Cita El paciente podr tener acceso al sistema para realizar consultas sobre fecha y hora de cita y as verificar su cita.

Todo usuario deber ingresar id y password el cual ser enviado a su mail, utilizando un SMTP (Simple Mail Transfer Protocol).

Actualmente se cuenta con 7 computadoras que son modelos desde Pentium I hasta IV con sistemas operativos que van desde Windows 98 hasta 2000, se han comprado paquetes de software por separado para realizar diferentes tareas como control de citas, inventario, ventas de productos (farmacia) y facturacin de citas. Debido a esta situacin hemos visto necesario el hacer un sistema integrado de las citas con los dems sistemas para cubrir las funciones que los pequeos paquetes tienen de forma integral de manera que haya una mayor comunicacin entre las reas y sistemas para que no haya tanto desorden. Por lo que se creara una vista con cdigo para cada usuario de manera que accedan de forma restringida y rpida a los datos que necesitan.

REQUERIMIENTOS DE TRANSACCIONES

Registrar Cita

- Ficha Clnica - Informacin referida a Doctores. - Horarios disponibles de Doctor. - Horario de cita disponible.

Eliminar Cita - Fecha y hora de la cita que se desea eliminar. - Horarios disponibles del Doctor.

Registrar Paciente

- Datos de Paciente - Datos Familiares

FASE INICIO

Captulo 1: Requerimientos

La visin recoge, analiza y define los requerimientos de alto nivel dados directamente por los futuros operadores del sistema SCCOA como tambin conocer el por qu del proyecto. En el plan de desarrollo de software vamos a asignar las tareas y roles, se apreciarn todas las responsabilidades que se realizaran durante el desarrollo de todo el proyecto. Hemos visto indispensable agregar una lista de riesgos ya que nuestro principal riesgo seria el de programacin, al presentar los prototipos al Administrador, en este caso el Sr. Dagoberto Camac, debemos estar en la posibilidad de realizar la programacin requerida una vez realizada la validacin del prototipo. El modelo de negocio se realizara a partir de la arquitectura de negocio, entonces es necesario agregar ese documento.

1.1. Documento Visin

Ver Anexo 1.

1.2. Plan de Desarrollo del Software

Ver Anexo 2.

1.3. Arquitectura del Software

Ver Anexo 3.

1.4. Glosario de Trminos

Ver Anexo 4.

1.5. Lista de Riesgos

Ver Anexo 5.

Captulo 2: Modelo Del Negocio

A partir de los objetivos identificados y los procesos realizados en la organizacin obtenemos los casos de uso del negocio.

Casos de Uso del Negocio:

_Gestionar Cita

_Inscribir Paciente

_Generar Reporte

_Llenar Ficha Clnica

Se realizaron Especificaciones de Casos de Uso de negocio donde encontramos los diagramas de actividades. En los diagramas de actividades anotamos los datos que se pasan entre actividades para realizar el modelo conceptual. Luego las actividades relevantes, realizadas por acores y que se van a automatizar, pasan a ser Casos de Uso del sistema.

2.1 Modelo de Casos de Uso del Negocio (MCUN)

Ver Anexo 6

2.2 Especificacin del Caso de Uso del Negocio (ECUN)

Ver Anexo 7

2.3 Diagrama de Actividades del Proceso del Negocio (PN)

Los diagramas de actividades sirven para modelar el flujo de control entre actividades que tiene lugar a lo largo del tiempo, as como las tareas concurrentes que pueden realizarse a la vez.

Sirven para representar el sistema desde otra perspectiva, complementando a los diagramas vistos anteriormente.

Dentro de cada especificacin de Caso de Uso de Negocio encontramos los diagramas de actividades del Proceso de Negocio.

Ver Anexo No. 8

2.4 Modelo de Objetos del Negocio (MON)

Ver Anexo 9

Captulo 3: Captura de Requerimientos

3.1 Modelo Conceptual o Lgico

Para realizar el Modelo Lgico y Conceptual seguimos los siguientes pasos: Identificacin de Clases Identificacin de Herencias y Agregaciones Identificacin de Asociaciones entre Clases Identificacin de Atributos de las Clases Estructurar el Modelo Lgico

Ver Anexo 10

3.2 Modelo de casos de Uso (MCU)

Este flujo de trabajo se efecta despus de haber capturado todos los requerimientos del sistema a desarrollar. Encontrar Actores y Casos de Uso

Propsito de esta actividad: Encontrar la funcionalidad del sistema. Definir lo que ser manejado por el sistema y qu ser manejado fuera del sistema. Definir quines o quin interactuar con el sistema Divide el modelo dentro de paquetes con actores y casos de uso. Crea diagramas del Modelo de Casos de Uso. Desarrolla una revisin del Modelo de Caso de Uso. Priorizacin de los Casos de Uso

Ver Anexo 11 Estructurar el MCU (Actores y CU)

Un Caso de Uso define un conjunto de instancias de casos de uso, donde cada instancia es una secuencia de acciones que el sistema puede llevar acabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia. Un Actor define un conjunto coherente de roles que los usuarios del sistema pueden asumir cuando interactan con l. Una instancia de un actor puede ser asumida por un individuo o un sistema externo

Ver Anexo 12

FASE ELABORACIN

Captulo 4: Anlisis O.O

1 Anlisis de la Arquitectura

La Arquitectura de Software es la Organizacin o Estructura de los Componentes ms importantes del Sistema y que interactan a travs de sus interfaces.

4.1.1. Identificacin de los Paquetes del Anlisis

Los casos de uso que tiene comportamiento comn y son relevantes entre ellos, conceptual y semnticamente, se agrupan en los paquetes de anlisis. Los casos de uso en cada paquete deben tener alta cohesin entre ellos y bajo acoplamiento con otros paquetes.

Descomponer el sistema en paquetes tiene la ventaja de modularizar el sistema hacindolo ms fcil de entender, manejar y documentar. Cada paquete puede resultar ser un futuro subsistema en la fase de diseo.

Deben ser altamente cohesivos (llevar a cabo una sola funcin) y estar dbilmente acoplados (interfase con otros paquetes con el mnimo de informacin)

Caractersticas: Pueden representar separacin de intereses de anlisis

 Crearlos basndose en los requisitos funcionales y en el dominio del problema, nunca en los requisitos especiales o en el dominio de la solucin. Servir probablemente como subsistemas en el modelo de diseo. Agrupar casos de uso en paquetes segn: Soporte a un determinado Proceso de Negocio Soporte a un determinado actor del sistema Relaciones de generalizacin y d extensin entre casos de uso 1er paso. Hemos agrupado los casos de uso: Eliminar Cita Asignar Horario de Cita Registrar Cita Dentro del paquete Gestionar cita, dando soporte al proceso de negocio Pedir Cita 2do Paso. Hemos visto necesario incluir en el mismo paquete Gestionar Cita al caso de uso Registrar Paciente debido a la relacin de extensin que existe con el caso de uso Registrar Cita 3er Paso. Hemos visto necesario incluir en el paquete Gestionar Citas, para dar soporte a los otros procesos del negocio.

Hay alta cohesin entre estos casos de uso.

4to Paso.- Capa General de la aplicacin Creamos otro paquete llamado Gestionar Cita donde agrupamos las carpetas anteriormente mencionadas Creamos otra carpeta

en la Capa General de la aplicacin llamada Gestionar Ficha Clnica donde agrupamos los casos de uso: Actualizar datos del paciente Seguimiento del paciente

5to Paso.- Definicin de Dependencias.

Existe una relacin de dependencia entre el paquete Gestionar Cita y Gestionar Ficha Clnica debido a que en la primera se encuentra el caso de uso Registrar Paciente que genera la Ficha Clnica. [pic] Anlisis de paquetes: [pic] Paquetes de Anlisis con sus respectivos Casos de Uso [pic]

4.1.2 Identificacin de Clases de Entidad Obvias

Hemos identificado las clases de entidad ms importantes, sin embargo conforme avancemos el proyecto se identificarn ms clases (Al hacer las RCUAnlisis y luego de Diseo). Principales abstracciones [pic]

4.1.3 Identificar los requisitos especiales comunes.

Tiempo de Respuesta Restricciones de memoria Tolerancia a fallas

 Interacciones con Sistemas Externos Seguridad Control de Acceso Persistencia

2 Analizar un Caso de Uso

Objetivos:

Identificar las clases que ejecutan el flujo de eventos de los Casos de Uso. Distribuir el comportamiento de los Casos de Uso entre las Clases Identificar las responsabilidades, atributos y asociaciones de las Clases

Pasos:

Precisar las descripciones de los Casos de Uso de Anlisis El documento de especificaciones de caso de uso nos describe cada Caso de Uso.

Ver Anexo 12

Para cada realizacin de Caso de Uso de Anlisis: Encontrar las Clases de Anlisis a partir del comportamiento del Caso de Uso. Distribuir el comportamiento entre las Clases del Anlisis.

MVC Anlisis: Registrar Cita [pic] MVC Anlisis: Verificar Horario de Cita

[pic]

MVC Anlisis: Consultar Cita

[pic] MVC Anlisis: Determinar Horario de Atencin por mdico [pic]

MVC Anlisis Eliminar Cita [pic]

MVC Ingresar descripcin de cita [pic]

MVC Anlisis Verificar Horario de Cita [pic] MVC Anlisis Registrar Paciente [pic]

4.3. Realizaciones de los Casos de Uso de Anlisis

Los Diagramas de Secuencia sirven para Analizar y disear cada uno de los casos de Uso. Se realiza en la Fase de Elaboracin y es el Flujo de Trabajo Diseo OO.

Estos diagramas nos van a permitir entender mejor la interaccin de c/u de los

Actores del Sistema con los Casos de Uso y los diferentes objetos que participan para que se pueda realizar el objetivo funcional del sistema.

Un DS muestra una interaccin ordenada segn la secuencia temporal de eventos, en particular muestra los Objetos participantes y los Mensajes que intercambian segn la secuencia de tiempo.

Ver Anexo 13.

4.1.5 Construccin de prototipos de la Interfase Grfica de Usuario (GUI)

Ver Anexo 14.

4.1.6 Modelo de Experiencia-del Usuario (MUX) Mapas de Navegacin.

Ver Anexo 15.

CAPTULO 5: DISEO O.O ORIENTADO A LA WEB

5.1.1 Modelo de diseo

El Modelo de Diseo muestra la forma que tendr el sistema, de manera que soporte todos los requisitos funcionales y no funcionales y otras restricciones del sistema. El Modelo de Diseo describe la realizacin fsica en modelos de objetos.

[pic]

5.1.2 Identificar Tcnicas de diseo

Identificar clases y subsistemas del modelo de anlisis. 1. Clases Perimetrales Clases Perimetrales de Formularios se Convierten en Paginas Web Cada clase perimetral que representa un formulario se convierte en una pgina servidor o una pgina cliente o una combinacin de las 2. Todas las pginas que contienen forms se convertirn en paginas servidoras. La relacin entre una pagina servidora y un form es el . La relacin entre una pgina cliente y una pgina servidora es: . Por ello se puede decir que una pagina servidora construye una pagina Web. Todas las pginas dinmicas (aquellas cuyo contenido se determina en runtime) son construidas con una pagina servidora y toda clase cliente es construida a lo ms por una pagina servidora, pero es posible que una pagina servidora construya mltiples pginas cliente. Una relacin comn entre pginas Web es el Hyperlink. El siempre se origina en la pgina cliente y va hacia otra pgina cliente o pgina servidora. El principal mecanismo de entrada de datos para paginas Web es el formulario, cada form especifica la pgina a la cual es submit, un formulario contiene un Nro de elementos de entradas expresados en etiquetas html, las mas comunes son input, select y textarea. A continuacin se muestra las Clases Perimetrales de Formularios del Sistema LOGIN WEB

[pic]

VERIFICAR HORARIO DE CITA (WEB)

[pic]

REGISTRAR PACIENTE

[pic]

REPORTE PACIENTES ATENDIDOS

[pic]

INGRESAR DESCRIPCION DE LA CITA

[pic]

ACTUALIZAR DATOS DEL PACIENTE

[pic]

ASIGNAR HORARIO DE CITA

[pic]

CONSULTAR CITA

[pic]

ELIMINAR CITA

[pic]

DETERMINAR HORARIO DE ATENCION POR MEDICO

[pic]

REGISTRAR CITA

[pic]

SEGUIMIENTO DEL PACIENTE

[pic]

Clases Perimetrales Externas se Convierten en EJBs El sistema SCCOA no utiliza sistemas o dispositivos externos. Cada clase perimetral que representa un dispositivo o sistema externo se convierte en un Enterprise Java Bean (EJB). Los motivos se explican a continuacin: EJB es la tecnologa ms compleja de J2EE y es el rompecabezas ms grande de J2EE. Esto puede hacer que los desarrolladores usen EJBs por razones equivocadas: porque la experiencia EJB se vea bien en su Curriculum Vitae; porque existe una creencia que usar EJB es una mejor prctica; porque EJB se percibe como la nica manera de escribir los cdigos de las aplicaciones Java; o solo porque EJB existen. EJB es una tecnologa high-end. Soluciona ciertos

problemas muy bien, pero no debe ser usado sin una buena razn. En esta seccin tomaremos una mirada desapasionada como las implicaciones de usar EJB y consideraciones importantes que influenciaran la decisin de usar un EJB. Incluir la tecnologa EJB tiene las siguientes implicaciones prcticas, que deben tenerse en cuenta: Usar EJB hace aplicaciones ms difciles de probar. Las aplicaciones distribuidas son siempre ms difciles de probar que los usos que funcionan en un solo JVM. Los usos de EJB - si utilizan interfaces remotas o locales - son duros de probar, pues son pesados de probar, como son muy dependientes del container services. Usar EJB hace las aplicaciones de despliegue difciles Complex deployment descriptors Mientras que algo de la complejidad de los EJB deployment descriptors reduce la complejidad en cdigo de EJB (con respecto a la gerencia de la transaccin, por ejemplo), la otra complejidad es gratuita. Las herramientas pueden ayudar aqu, pero es preferible evitar la complejidad ms bien que confa en las herramientas para manejarla. o Ciclos de development-deployment-test ms lentos. EJBs usar EJB puede reducir productividad del desarrollador. La mayora de las frustraciones prcticas con J2EE se relacionan con EJB. sta no es ninguna preocupacin trivial; cuesta tiempo y el dinero si EJB no entrega ventajas que compensan. EL uso de EJB hace de pequeos problemas dificultades Algunas cosas simples son sorprendentemente difciles en EJB (in interfaces remotas o locales) Por ejemplo es difcil implementar el patrn Singleton design y tener data de solo lectura. ELB es una tecnologa muy pesada y hace el trabajo pesado de simples problemas. Reduce la eleccin de servidores de aplicacin

Hay algunos Web containers que EJB containers, y Web containers tienden a ser mas fciles que EJB containers. Una aplicaron Web solo puede correr en una gama de servidores mas estrecha y barata comparada con la aplicacin EJB, con simple configuracin y despliegue 1. Clases de Control Cada clase de control se convierte en un despachador de casos de uso. Clases Controladoras : Servlet [pic]

2. Clases de Entidad Clases de entidad cercanas se posicionan bajo la misma EJB. Los beans identificados son: [pic] [pic]

5.1.3. Diseo de Casos de Uso

El diseo de un caso de uso es similar al anlisis de caso de uso, las relaciones y operaciones se determinan creando una Realizacin de Caso de Uso para cada caso de uso. La diferencia es que se usan elementos de diseo (en lugar de elementos de anlisis) cuando se realiza el Caso de Uso. Por ejemplo, veremos el uso de interfaces en los diagramas de secuencia asociados a la Realizacin de Caso de Uso.

El comportamiento definido en los casos de uso es distribuido hacia las Clases de Diseo e Interfaz que han sido identificadas.

 Esto permitir determinar (o calificar si ya est especificado) las relaciones entre Clases de Diseo, y tambin asignar responsabilidades a las Interfaces y Clases de Diseo.

Para el anlisis de casos de uso, asociados con cada Realizacin de Caso de Uso son uno o varios diagramas de secuencia que muestran la interaccin entre las Interfaces y Clases de Diseo, con operaciones identificadas. Para poder apoyar el rastro, cada Realizacin de Caso de Uso tambin contiene un diagrama de clases mostrando las clases que participan en la Realizacin de Caso de Uso.

5.1.4. Realizaciones de casos de uso en la Web

Proporciona una realizacin fsica de la realizacin de C.U.anlisis para el que es trazado.

[pic]

[pic]

[pic]

Ver Anexo 16 : Especificacin de caso de usos de diseo

7 Diagrama de Clases de Diseo

Una de las metas es la de disear una aplicacin separando la lgica de negocio de la lgica de presentacin. Uno de los patrones ms populares es el

de la arquitectura MVC. Este patrn divide tres principales componentes: Modelo, Vista y Controlador. El modelo se refiere a la aplicacin del modelo de datos, la vista representa la lgica de presentacin y el controlador la lgica entre los dos y permite al usuario interactuar con la vista y el modelo. La implementacin del MVC es usualmente implementada como sigue:

MVC : Asignar Horario de cita

[pic]

MVC Consulta cita [pic]

MVC Eliminar Cita [pic] MVC Horario de Atencin por mdico [pic] MVC Ingresar Descripcin de Cita [pic]

MVC Registro de citas

[pic]

8 Modelo de Persistencia

Ver anexo 17

5.1.4 Script

Ver anexo 18

CAPITULO 6 : MODELO DE IMPLEMENTACIN

La implementacin permite la integracin del sistema y la implementacin de las clases y subsistemas El Modelo de Implementacin es una coleccin de componentes, y los subsistemas de implementacin que los contienen. Es una vista arquitectnica que describe uno o varias configuraciones del sistema. Define, executables, dll, files, subsistemas, compilacin, etc.

6.1.1.Diagrama de Paquetes

[pic]

6.1.2.Diagrama de Componentes

El diagrama de componentes es usado para organizar la implementacin del modelo. Este diagrama muestra la localizacin de clases y objetos en los componentes implementados. Un componente de software es un mdulo o subsistema que completa una funcin clara , tiene lmites claros y puede ser integrado en una arquitectura bien definida.

Diagrama de componentes:

[pic]

6.1.4. Diagrama de Distribucin (considerando la WEB)

El Diagrama de distribucin define las configuraciones de la red fsica tpica, incluyendo aquellos usados por los usuarios finales , as como las configuraciones especiales que se usaron para el desarrollo y prueba. Este diagrama est formado por nodos. Cada nodo es un objeto es un objeto fsico que representa alguna clase de unidad de cmputo, en la mayora de los casos se trata de una pieza de hardware. Entre los nodos se establece una comunicacin.

DIAGRAMA DE DISTRIBUCIN SCCOA

[pic]

FASE DE CONSTRUCCIN

CAPTULO 7 : CODIFICACIN

La construccin se hace mediante un Lenguaje de Programacin OO. Para nuestro caso se utilizar Eclipse. Los mdulos que va ha tener nuestro sistema lo obtenemos del MCU Se tendr una GUI para interactuar con el sistema adems de una ventana de Acceso al sistema para la identificacin del sistema. El caso de uso a implementar es el Caso de Uso Registrar Paciente.

1 Implementacin Paso a Paso

Primer Paso: Generar cdigo de componentes en rational J2ee Provee un modelo de desarrollo de aplicaciones basado en componentes. La especificacin J2EE define las siguientes componentes: Componentes Cliente: Pginas HTML, Applets y Aplicaciones Cliente Java Componentes Web: Servlets y JSP (JavaBeans, Custom Tags) Componentes Empresariales: Enterprise JavaBeans Para implementar estos diseos usando stos componentes requiere una clase de web server llamado contenedor servlet. Tomcat, de la Apache Organizations Jakarta project es el contenedor servlet estndar. Tomcat y Apache software son free y open source.

[pic]

Segundo Paso: Instalacin de Servidores:

Que servidores vamos a usar? Eclipse es una plataforma para la integracin de herramientas creada por una comunidad de proveedores de herramientas. La plataforma Eclipse opera con un paradigma de cdigo abierto y una licencia pblica comn que ofrece cdigo fuente libre de royalties y derechos de redistribucin para todo el mundo. Tomcat es un contenedor de Servlets con un entorno JSP. Un contenedor de Servlets es un shell de ejecucin que maneja e invoca servlets por cuenta del usuario.

 Pasos de la instalacin:

Paso 1 Instalar JDK 1.4.1_02

Paso 2 Crear variable de entorno con la ruta del j2sdk instalado. Ir a panel de control ( sistema ( variable de entorno Crear: JAVA_HOME C:/j2sdk

Paso 3 Como estamos usando Tomcat 5.5 con JDK 1.4 (recomendable), tambin se debe descargar el archivo zipeado: Compat.zip. Debemos dezipear las carpetas y ubicarlos dentro de la carpeta de Jakarta. Para saber si nuestra instalacin se realiz correctamente probamos de la siguiente forma:http://localhost:8080/

Aparecer la siguiente pgina: [pic]

Paso4

Instalar Eclipse Instalar TomcatPluginV3: Plugin Tomcat Sysdeo de Apache web site: para poder desarrollar proyectos orientados a la Web. Se debe configurar y aparecen tres botones en el IDE de Eclipse una vez configurado.

Descomprimir el plugin en la carpeta plugins de eclipse Configuracin: http://www.programacion.net/java/articulo/jap_eclip_4/ WTP http://www.eclipse.org/webtools/testtutorials/M2/webapptutorial/BuildingASchedule WebApp.html

JRE ("Java Runtime Environment")

Como su nombre lo indica este ambiente ("KIT") es utilizado solo para ejecutar ("Runtime") programas en Java.

JDK,SDK,J2SE

"Java Development Kit"(JDK),"Standard Development Kit" (SDK) y "Java 2 Standard Edition" (J2SE) son nombres para el mismo componente e incluyen: El API de Java, el JRE ( JVM ), compilador de Java y otras funcionalidades definidas por Sun. El API de Java es un conjunto de clases que es utilizado para generar programas bsicos en el lenguaje; utilizando una analoga, estas clases tienen la misma funcionalidad que las funciones|clases estndar utilizadas en otros lenguajes C,C++, Perl (Esto es precisamente la definicin de API ("Application Programming Interface")). Partiendo de estas clases (API de Java) se generan TODOS los programas, interfaces y elementos programados en Java, inclusive a partir de estas clases usted puede definir otras clases especficas que sern utilizadas por su programa o producto. Una vez que defina sus programas clases en Java an es necesario compilarlas para producir lo que es denominado byte-code o class files (este bytecode puede ser comparado con un binario) , y es este byte-code el que interpreta

el JRE("Java Runtime Environment").Este byte-code es el que directamente ofrece la interoperabilidad de Java o el afamado "Write once run everywhere"="Escribalo una vez ejecutelo en todos lados". Tercer Paso: Crear Proyecto Tomcat Creamos en Eclipse un TOMCAT Proyect SCCOA0.1 y aadimos: Bienvenido.jsp RegistrarPaciente.jsp E importamos los componentes

[pic]

Cuarto Paso: Creacin de JSPs y Servlets

Al crear los servlets debe tener una superclase javax.servlet.http.HttpServlet como vemos en la figura. Tipos de Servlet:

1. GenericServlet Subclase directa: httpservlet Define una genrico servlet independiente del protocolo.

2. HttpServlet Para escribir un servlet HTTP para uso en la Web.

[pic]

JSP

Una pagina JSP es una pagina creada por el desarrollador web que incluye tecnologa JSP y tags personalizables, en combinacin con otras tags estticas (HTML o XML). La tecnologa JavaServer Pages (JSP) provee una simplificada, manera rpida de crear contenido web dinmico. Permite rpido desarrollo de aplicaciones. RegistrarPaciente.jsp Creamos en el proyecto un archivo jsp: New ( File y luego escribimos RegistrarPaciente.jsp Antes hacemos que eclipse reconozca el jsp, para ello debemos ir al men Windows( Preferentes ( Team ( FileContent y agregamos jsp (asegurarse que diga ASCII) Es recomendable que los nombres de los botones, textfields, etc. estn con el correcto formato, por ejemplo: txtPat, txtMat, btnApePat. En el jsp debemos tener en cuenta Nomenclatura ya que luego usaremos estas variables: Personales:

Nombre:

Apellido Paterno:

Codificacin

Vamos a usar: Mtodos Get y Post Todo cliente se comunica utilizando mtodos post y get. Post Permite al cliente enviar data de longitud ilimitada al servidror Web. Ej. cuando posteamos informacin como los numeros de una tarjeta de credito. Get Permite al cliente pedir informacin. Tambin se puede enviar informacin pero los datos son enviados por el URL. Para obtener los valores: getParameter() method, que retorna Strings. FrontController Este elemento provee un controlador centralizado para gestionar las peticiones webs a la aplicacin. Un controlador frontal recibe todas las peticiones entrantes de los clientes, remitiendo a su vez cada peticin al gestor de peticiones (Dispatcher) adecuado, que se encargar de gestionar la construccin de una respuesta adecuada al cliente. Son los puntos ideales para implementar servicios de seguridad, tratamiento de errores, y la gestin del control para la generacin de contenidos.

public class ControladorFrontalServlet extends HttpServlet{

protected void doPost(HttpServletRequest req,HttpServletResponse res)throws ServletException, IOException { processRequest(req , res); }

protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException {

String action = request.getParameter("op") ; // el directorio al que enviar la peticin "despachada" String dispatch ="/SCCOA0.1/servlet/org.eclipseproject.sccoa." ; Dispatcher Tendremos toda una coleccin de estos elementos. En cada uno codificaremos la construccin de la respuesta al usuario. Bsicamente lo que hacen es componer vistas y configurar estas para que muestren la informacin adecuada como respuesta a la peticin del usuario. El controlador delega sobre el dispatcher la presentacin de un elemento lgico. El dispatcher se encarga de resolver la indireccin y proporcionar el elemento fsico.

if(action == "registrarpaciente") dispatch += "RegistrarPacienteServlet" ;

if(action == "Entrar") dispatch += "VerificarHorarioDeCitaServlet";

// crea el dispatcher al que reenviarle la solicitud RequestDispatcher dispatcher = request.getRequestDispatcher(dispatch); // reenvia la peticin dispatcher.forward(request, response) ;

SQL Driver y Conexin Necesito el Driver JDBC y lo coloco en SCCOA0.1/WEB-INF/lib El cdigo es el siguiente: Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver"); Connection connection = DriverManager.getConnection("jdbc:microsoft:sqlserver://127.0.0.1:1433;dataBase Name=SCCOA0.2","sa","spiderman"); Para Registrar Paciente uso el siguiente cdigo: stm= connection.createStatement(); stm.executeUpdate("insert into Paciente(apePat,apeMat,nombre,edad,fecNac,estadoCivil,direccion,mail,pwd,usua rio) values('"+nombre+"','"+apePat+"','"+apeMat+"','"+edad+"','"+fecNac+"','"+estCivil+"' ,'"+direccion+"','"+mail+"','"+pwd+"','"+ usuario+"')");

Si tuviera que obtener datos de la tabla uso: Usamos el ResultSet q es como un DataSet en .NET try{ Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver"); Connection connection =

DriverManager.getConnection("jdbc:microsoft:sqlserver://127.0.0.1:1433;dataBase Name=SCCOA0.2","sa","spiderman");

stm= connection.createStatement(); ResultSet rst= stm.executeQuery("select * from Paciente where usuario='"+usuario+"' and pwd='"+pwd+"'");

if(rst.next()){ out.println(rst.getString("nombre")); out.println(rst.getString("apePat")); }

}catch(ClassNotFoundException e) { out.println("Couldn't load database driver: " + e.getMessage()); }

Como vemos usamos a diferencia del anterior el Result Set y un Query: El resultado de un SQL Query es almacenado en un result-set. Con Query por ejemplo, hemos realizado la consulta web del paciente:

Dentro de un servlet podemos agregar cdigo html: (son pginas dinmicas) if(rst.next()){

out.print(""+rst.getString("nombre")+" "+rst.getString("apePat")+"");

Que es un Ant? En Linux existe una utilidad llamada Make la cual compila el proyecto siguiendo una determinada secuencia, no es universal, depende de la plataforma. El Ant nos va a permitir compilar una sola vez. Por ejemplo, tengo un proyecto donde tengo una clase A que depende de otra clase B, generalmente tendria que compilar primero B para que funcione correctamente A. Pero con Ant tendra que compilar slo una vez. Ant sigue la secuencia definida en formato XML. Ant es una herramienta open source para construir (build) de la Apache Software Foundation.

7.1.2. Interfase grfica del Usuario (GUI)

Ver Anexo 14

7.1.4. Estructura de Base de Datos

Para ver el Script generado : Ver Anexo 18

7.1.5. Conexin del Software con la Base de Datos

Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver"); Connection connection = DriverManager.getConnection("jdbc:microsoft:sqlserver://127.0.0.1:1433;dataBase Name=Test","sa","spiderman");

Ubicacin del Driver SCCOA0.1/WEB-INF/lib

CAPTULO 8 : MODELO DE PRUEBAS

En este captulo se verificar el resultado de la implementacin Para ello se mencionar las tareas que se deben realizar para probar un software, las tcnicas utilizadas, y la cobertura de caminos.

Las tareas a realizar para probar un software: 1. Diseo de las pruebas. Esto es, identificacin de la tcnica o tcnicas de pruebas que se utilizarn para probar el software. Distintas tcnicas de prueba ejercitan diferentes criterios como gua para realizar las pruebas. Seguidamente veremos algunas de estas tcnicas. 2. Generacin de los casos de prueba. Los casos de prueba representan los datos que se utilizarn como entrada para ejecutar el software a probar. Ms concretamente los casos de prueba determinan un conjunto de entradas, condiciones de ejecucin y resultados esperados para un objetivo particular. Como veremos posteriormente, cada tcnica de pruebas proporciona unos criterios distintos para generar estos casos o datos de prueba. 3. Definicin de los procedimientos de la prueba. Esto es, especificacin de cmo se va a llevar a cabo el proceso, quin lo va a realizar, cundo. 4. Ejecucin de la prueba, aplicando los casos de prueba generados previamente e identificando los posibles fallos producidos al comparar los resultados esperados con los resultados obtenidos. 5. Realizacin de un informe de la prueba, Con el resultado de la ejecucin de las pruebas, qu casos de prueba pasaron satisfactoriamente, cules no, y qu fallos se detectaron. Tras estas tareas es necesario realizar un proceso de depuracin de las faltas asociadas a los fallos

identificados. Nosotros nos centraremos en el segundo paso, explicando cmo distintas tcnicas de pruebas pueden proporcionar criterios para generar distintos datos de prueba.

Tcnicas de Prueba Las tcnicas de evaluacin dinmica o prueba proporcionan distintos criterios para generar casos de prueba que provoquen fallos en los programas. Estas tcnicas se agrupan en: Tcnicas de caja blanca o estructurales, Tcnicas de caja negra o funcionales, Pruebas de Caja Blanca o Estructurales Este mtodo se centra en cmo disear los casos de prueba atendiendo al comportamiento interno y la estructura del programa. Se examina as la lgica interna del programa sin considerar los aspectos de rendimiento. El objetivo de la tcnica es disear casos de prueba para que se ejecuten, al menos una vez, todas las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como falsa. Como se ha indicado ya, puede ser impracticable realizar una prueba exhaustiva de todos los caminos de un programa. Por ello se han definido distintos criterios de cobertura lgica, que permiten decidir qu sentencias o caminos se deben examinar con los casos de prueba. Estos criterios son:

- Cobertura de Sentencias: - Cobertura de Decisin: - Cobertura de Condiciones: - Cobertura Decisin/Condicin: - Cobertura de Condicin Mltiple: - Cobertura de Caminos

Cobertura de Caminos La aplicacin de este criterio de cobertura asegura que los casos de prueba diseados permiten que todas las sentencias del programa sean ejecutadas al menos una vez y que las condiciones sean probadas tanto para su valor verdadero como falso. Una de las tcnicas empleadas para aplicar este criterio de cobertura es la Prueba del Camino Bsico. Esta tcnica se basa en obtener una medida de la complejidad del diseo procedimental de un programa (o de la lgica del programa). Esta medida es la complejidad ciclomtica de McCabe, y representa un lmite superior para el nmero de casos de prueba que se deben realizar para asegurar que se ejecuta cada camino del programa. Los pasos a realizar para aplicar esta tcnica son: - Representar el programa en un grafo de flujo - Calcular la complejidad ciclomtica - Determinar el conjunto bsico de caminos independientes - Derivar los casos de prueba que fuerzan la ejecucin de cada camino. A continuacin, se detallan cada uno de estos pasos. Representar el programa en un grafo de flujo El grafo de flujo se utiliza para representar flujo de control lgico de un programa. Para ello se utilizan los tres elementos siguientes: - Nodos: representan cero, una o varias sentencias en secuencia. Cada nodo comprende como mximo una sentencia de decisin (bifurcacin). - Aristas: lneas que unen dos nodos. - Regiones: reas delimitadas por aristas y nodos. Cuando se contabilizan las regiones de un programa debe incluirse el rea externa como una regin ms. - Nodos predicado: cuando en una condicin aparecen uno o ms operadores lgicos (AND, OR, XOR, ...)

8.1.2. Preparacin de un Caso de Prueba

El Caso de Uso preparado para realizar las pruebas respectivas es el Caso de Uso Registrar Paciente. Se ha preparado la documentacin respectiva en la cual se especifican los procedimientos de la prueba, las pruebas funcionales y las pruebas de rendimiento.

Ver Anexo 18

CONCLUSIONES Es muy importante estar en contacto con los usuarios del sistema y los que toman las decisiones dentro de la organizacin (stakeholder) para su aprobacin. El RUP nos permite asignar tareas y responsabilidades, facilitando la determinacin de: quien hace que, cuando y como. A travs de cada etapa y cada flujo de trabajo se fue obteniendo un producto software que cumpla de manera eficiente con las especificaciones de los requerimientos de los usuarios.

Concluiremos sealando un punto importante, sobre todo, en el tema de los patrones orientados al desarrollo de aplicaciones con tecnologa J2EE. El mercado est considerando seriamente, la implementacin de soluciones basadas en el paradigma de programacin orientada a objetos, en tanto no existe una oferta que satisfaga dichos requerimientos del mercado con un nivel aceptable de calidad y que, a largo plazo, asegure la permanencia de los productos de software y

disminuya radicalmente los costos de produccin y mantenimiento. Para el desarrollo de SCCOA(Sistema de Control de Citas de la Oftalmolgica ASMAT), el grupo desarrollador ha empleado la notacin UML la cual se fundamenta en principios de modelado, lo cual ha sido muy importante para la implementacin de dicho sistema. Los diagramas a utilizar en las diferentes etapas del desarrollo de los sistemas de informacin, pueden variar dependiendo del tamao y tipo de sistema, por lo que es necesario organizarlos segn las fases del Proceso Unificado. EJB es la tecnologa ms compleja de J2EE y es el rompecabezas ms grande de J2EE, razn por la cual el grupo desarrollador GIC ha hecho uso de Java Beans debido a que se ajusta a las necesidades de nuestro proyecto.

RECOMENDACIONES Apreciamos las ventajas y virtudes que nos brinda la metodologa RUP en comparacin con otras usadas todava en muchas organizaciones del mercado peruano renuentes al cambio y a la innovacin. Debido a la ausencia de manuales que sirvan de apoyo a los alumnos en la implementacin de Proyectos de Software, el equipo adjunta un CD con un conjunto de manuales conteniendo informacin sobre el tema. La documentacin del Proyecto SCCOA contiene en cada uno de sus captulos la informacin terica necesaria; que creemos ser de gran de gran ayuda en la elaboracin de proyectos. Queda a disposicin de los lectores

toda la informacin recopilada para aquellos que desearan continuar con la implementacin completa del software. Se recomienda que el Sistema sea manejado por personas capacitadas, para su mejor uso. El tiempo que se da para implementar el proyecto es muy corto, teniendo en cuenta la complejidad de la programacin en J2EE y la poca experiencia de la gran mayora de los alumnos en el uso de este tipo de herramientas. El equipo recomienda que en el curso de Software II se dedique mayor tiempo y asesoramiento a la Fase de la implementacin.

BIBLIOGRAFA

1. JACOBSON, Ivar BOOCH, Grady RUMBUGH James. EL PROCESO DE DESARROLLO DE SOFTWARE Ed. Addison Wesley. Madrid 2000. 2. PRESSMAN, Roger S. Ingeniera de Software Ed. Mc. Graw Hill, Espaa 1997 3. Muller, Pierre-Alain. INSTANT UML Ed. Wrox Press Ltda. Canada 1997 4. Rational Rose _ Rational Unified Process www.rational.com 5. McGraw-Hill - Practical J2EE Application Architecture - 2003.chm 6. Java - Wrox - Expert One-on-One J2EE Design and Development.chm 7. Building J2EE Applications With RUP.chm 8. Proyecto Eclipse.pdf 9. Teach Yourself JSP 2.0 with Apache Tomcat in 24 Hours (Sams, 2003).chm

10. O'Reilly - Tomcat Definitive Guide 2003.pdf 11. [eBook] - O'Reilly - Apache Cookbook.chm 12. (ebook) - La biblia del servidor Apache (spanish - espaol).pdf 13. Prentice Hall - Aprendiendo UML en 24 horas.pdf 14. Wiley - UML Weekend Crash Course.pdf 15. Addison Wesley - UML Design Patterns Java.PDF 16. Auerbach Publications - Software Architecture Design Pattern.pdf 17. Wiley - J2EE Best Practices - Java Design Patterns, Automati.pdf 18. Java - Wrox - Expert One-on-One J2EE Design and Development.chm 19. McGraw-Hill - Practical J2EE Application Architecture.chm 20. MSPress-SMS 2003 Administrators Companion (2004).chm 21. Prentice Hall - Core J2EE Patterns Best Practices and Design.pdf

ANEXOS

Anexo 1: Visin SCCOA

Sistema de Control de Citas Oftalmolgica Asmat Visin del Proyecto Versin 1.2

Visin del Proyecto

1. Introduccin

1.1 Propsito

El propsito de este documento es recoger, analizar y definir los requerimientos de alto nivel del Sistema de Control de Citas Oftalmolgica Asmat (SCCOA). Se enfoca en percibir y distinguir las necesidades reales de los stakeholders y usuarios del sistema.

La idea principal es definir el sistema y manejar los requerimientos y sus cambios para poder encontrar la mejor solucin y validar decisiones futuras.

1.2 Alcance

Este documento involucra toda la informacin necesaria que sirva de base para la posterior construccin del SCCOA. El alcance de este proyecto se aplica al Sistema de Control de Citas de la Oftalmolgica Asmat (SCCOA). Este sistema automatizar y mejorar el desempeo del sistema actual e interactuar con los sistemas de las otras reas, de manera que permita, el registro, asignacin de horarios , consultas y control general de citas en la Clnica.

1.3 Definiciones y abreviaturas

SCCOA Sistema de Control de Citas de la Oftalmolgica Asmat.

1.4 Referencias

Manual Oftalmolgica Asmat. Entrevista con Administrador de Contabilidad, Sr. Dagoberto Camac.

2. Posicionamiento del Producto

2.1 Oportunidad de Negocio

Se busca sustituir al sistema actual de registro de citas y de nuevos pacientes por un sistema encargado del Control de Citas de la Oftalmolgica Asmat, el cual ser fcil, rpido y seguro y permita optimizar el trabajo de los usuarios. Se propone que el sistema cuente con un control eficaz de las citas y el manejo de una base de datos que permita manipular ordenadamente la informacin, que sea libre de errores y dispuesto a cambios para aumentar la productividad, reduzca tiempos de espera, satisfaga a los operadores del sistema y mejore la imagen de la oftalmolgica.

2.2 Definicin del Problema

|El problema de consistente en el sistema actual. | | | de control de citas. | | que se la necesita. | | un sistema de apoyo ni | | contingencia. |Afecta | | |

|No poseer una base de datos

|La poca eficacia y lentitud del proceso

|Informacin no disponible en el momento

|No tener un backup de seguridad, no hay

|plan de | |A los pacientes, secretarias, doctores y

administrativos

| |Serian los gastos innecesarios, | |requerido y los grandes perjuicios a los

|El impacto de este tiempo de proceso mayor del | pacientes, secretarias| | administradores. |Una solucin acertada brindara y segura. | | de manera fcil, rpida| | sistemas. | | cambios sin afectar el | | | | | | | | | | |y |

|Una base de datos confiable

|Acceso y recopilacin de la informacin

|y confiable, que sea compatible con otros

|Un back up de seguridad. Realizar

|sistema.

|Interfase Grfica de Usuario personalizada, es decir diseada | | requiere. | | por los pacientes. | | | | |de acuerdo a lo que el operador

|Consultas va Internet para verificar citas

Posicionamiento del Producto

|Para personal administrativo y gerentes| | oftalmolgica. |Quienes modifican data, generan reportes, | | procesos. |

|Los pacientes, personal medico,

|de la | |Consultan horarios, ingresan y

|conciertan citas y supervisan

|Sistema de Control de Citas Oftalmolgica Asmat software |Que reduciendo tiempos de espera a | acceso a datos adems de | mediante el cual los pacientes | horarios de citas. |A diferencia del y eficaz que cuenta con | trabaja con archivos planos. |Nuestro producto confiable y segura contando con | | | | | | | | |

|Es un producto de

|Permite eficaz control de citas

|travs de fcil y confiable ingreso y

|contar con informacin en lnea

|puedan consultar y verificar sus

|Sistema existente poco confiable

|herramientas Office, Access y se

|Proporciona informacin

|herramientas actualizadas y una base de datos consistente. |

3. Descripcin de usuarios y Stakeholders

Para proveer productos y servicios efectivamente se necesita conocer lo que el stakeholder y el usuario realmente necesita. Se debe identificar a los usuarios del sistema y sus requerimientos. Esta seccin explica el por que de estos requerimientos. En este caso los usuarios del sistema no solo son las secretarias tambin los pacientes ya que podrn tener acceso va Internet a los horarios para consultar y verificar sus citas. Las secretarias se encargan de registrar citas. Los doctores pueden modificar las citas. Los administrativos tomaran decisiones a partir del SCCOA. La informacin ser restringida de acuerdo a lo que necesita cada rea de la oftalmolgica para as poder contar con un sistema seguro.

3.1 Estadstica del Mercado

La oftalmolgica se divide en las siguientes reas: mdica, administrativa y contable. La oftalmolgica cuenta con un nmero limitado de personal, los cuales sern entrevistados para lograr obtener sus reales requerimientos. El mercado es relativamente grande pero incluye solo al sector medio y alto. Se busca crecimiento del mercado logrando tambin la atencin de pacientes provenientes de sectores bajos.

Resumen de Stakeholder:

|Nombre | |Gerente

|Representa

|Rol

|Jefes de Oftalmolgica Asmat. |

|Toma

decisiones. Aprueba o no el sistema. | | | rea. | |cada

|Supervisan buen funcionamiento de |

| |Gestiona de citas | |fechas establecidas |Registro de citas

|Personal Administrativo y comunica a los doctores las | previamente. | |

Resumen de Usuario

|Nombre |Descripcin |ACT7 Administrador decisiones. | y | | |ACT9 Secretaria solicitan | oftalmolgica. |ACT11 Paciente |Atencin y registros a los pacientes que | | |Gerente |Stakeholder |Aprueba o no el sistema. Tomador de | |

|Revisa calidad del sistema, su performance | |desarrollo. |

|Personal Administrativo |servicios de la |

|Solicita servicios de la

Oftalmolgica.

|Busca buena atencin de la clnica. |

3.2 Ambiente de los usuarios

Los pacientes conocen al doctor, por poltica de la empresa, la atencin es personalizada. Se trabaja en un ambiente amigable. Los pacientes se sienten seguros.

Cuenta con nmero limitado de personal, el personal es estable. Las consultas duran un promedio de 20 minutos. Actualmente se cuenta con 7 computadoras que son modelos desde Pentium I hasta IV con sistemas operativos que van desde Windows 98 hasta 2000, se han comprado paquetes de software por separado para realizar diferentes tareas como control de citas, inventario, ventas de productos (farmacia) y facturacin de citas. Se trabaja con herramientas de Microsoft Office, Access y los pequeos paquetes en Java.

Si el paciente es nuevo se le toman sus datos y se le pide que llegue unos minutos antes de la hora de su cita para llenar su Ficha Clnica. Luego de identificar al paciente se procede a coordinar con el mismo el horario ptimo para la cita dependiendo del doctor con el que el paciente decida atenderse y del tipo de cita. La hora y fecha de la cita coordinada y aceptada por el paciente se escribe en una agenda. Esto es debido al fcil transporte que tiene la agenda para llevarla a los administradores de la Oftalmolgica puesto que se necesita el reporte actualizado siempre. En caso ocurran incidentes como modificacin o cancelacin de citas se realizan en la misma agenda. Al final de cada da se transcriben las citas realizadas a un programa en Access que se encarga de almacenarlos y finalmente se imprimen 3 listados de citas uno para recepcin, otro para el doctor y otro para vigilancia.

Los pacientes que recurren a la Oftalmolgica Asmat son por lo general del sector medio y alto por lo que vemos fundamental la rapidez y eficiencia del proceso para que el paciente se sienta a gusto con el servicio que se le brinda. La Oftalmolgica Asmat tiene en proyecto expandirse captando al sector bajo mediante una sucursal en Pamplona donde se atender con la misma calidad de servicio pero enfocada a este sector ms necesitado.

3.3 Perfiles de Stakeholder

Gerente

|Representante Camac |Descripcin Asmat |Tipo objetivos a corto plazo y| | dentro de la Empresa. |Responsabilidades | |

|Sr. Dagoberto | |Administrador de la Oftalmolgica

|Entiende el estado financiero de la oftalmologa, los

|la visin a largo plazo. Persona que toma decisiones

|Administracin de la Oftalmolgica. Aprobar

los presupuestos y los proyectos. | | implementar. |Criterios Del xito |Supervisa que el proyecto se llegue a | |Espera un sistema de control de citas de

calidad. El xito es la implementacin| | oftalmolgica. |del proyecto en la |

|Implicacin proyecto |Entregables Gerentes. |Comentarios y Problemas el SCCOA. | | | |

|Durante la fase de inicio revisa entregables del

|Todos los entregables son revisados por los

|Que los clientes no estn satisfechos con

|Que no todos los gerentes estn de acuerdo con el

presupuesto sugerido por el | | GIC. |equipo |

Personal Administrativo |Representante Mundaca |Descripcin Asmat |Tipo SCCOA |Responsabilidades |Mariella | |Secretaria de la Oftalmolgica | |Usuario del | |Registro de citas y comunica a los doctores

las fechas establecidas previamente. | |Criterios Del xito |Espera un proceso rpido y seguro que |

cumpla sus expectativas y sea de fcil | | |Implicacin espera |Entregables |manejo.

|Disminuir tiempos de | |Ninguno

| |Comentarios/Problemas entorno desconocido para el personal. | sistema. |Falta de prctica en el uso del sistema, |

|No saber detectar las fallas bsicas del |

Perfil de Usuario

Gerente de Administracin de Contabilidad

|Representante Camac |Descripcin | |Tipo Oftalmolgica. |Responsabilidades implementar, y tiene autoridad sobre | |

|Sr. Dagoberto | |Administrador

|Entiende el estado financiero de la | |Supervisa que el proyecto se llegue a

|la aprobacin. Encargado de ver el proceso de la

empresa y supervisar cada | | empresa. |Criterios Del xito El xito es la | oftalmolgica. |Implicacin | |implementacin del proyecto en la | |Los reportes que se realicen se presentan al |rea de la | |Espera un sistema de control de citas de calidad.

administrador. Adems actualiza| | doctor decide | |Entregables | |Comentarios/Problemas | |Ninguno | |cambiar de turno. |Ninguno | |los horarios de los mdicos en el sistema, si es que el

Secretaria |Representante Mundaca |Descripcin Asmat |Tipo SCCOA |Responsabilidades |Mariella | |Secretaria de la Oftalmolgica | |Usuario del | |Registro de citas y comunica a los doctores las

fechas establecidas previamente. | | |Criterios Del xito expectativas y sea de fcil | |Implicacin espera |Entregables realiza reporte de citas |Comentarios/Problemas | | |Actualiza citas |

|Espera un proceso rpido y seguro que cumpla sus

|manejo. |Disminuir tiempos de | |Actualmente | |Falta de prctica en el uso del sistema,

entorno desconocido para el personal. |

| sistema. | sistema.

|No saber detectar las fallas bsicas del | |Principal usuario del |

Paciente

|Representante | |Descripcin cita. |Tipo | |Responsabilidades | |Criterios Del xito expectativas |Implicacin espera |Entregables | |Comentarios/Problemas sugerencias.

|Ninguno

|Solicita | |Paciente

|Ninguno

|Cumpla sus | |Reducir tiempo de | |Ninguno

|Puede dar |

3.4 Necesidades Claves del Stakeholder o Usuario

Se realizaron entrevistas al administrador, secretarias y personal medico para determinar las necesidades de estos usuarios en el uso del SCCOA:

|Necesidad Actual |

|Prioridad | |

|Preocupaciones

|Solucin

|Soluciones |

| |No existe un control de | |

|Propuestas

|Sistema de Control de |alta las |Citas | |Repositorio de la |Ninguna | | |alta | |SCCOA

|citas eficaz

|Procesos ms lentos referentes |Se registra

|Almacn de datos |

|Informacin

|a la bsqueda de informacin y |informacin de

la |directamente a la | | la | de | | | | |La generacin de reportes es |Al final de | |se generan | |computadora y fcil | | | |computadora y luego |generacin |generacin de repotes. |agenda en

reportes.|reportes.

|Generacin de reportes |alta cada da|Proceso que tenga la| | los | | |Procedimiento Formal de |alta existe back up |Back up |Backups que | | | | | |informacin lista y | | |

|lenta e insegura.

|se generan

|reportes.

|ordenada.

|No hay back up de recuperacin |No

|de informacin en caso de |

| borrada. |

| |

|la informacin sea | |La consulta es lenta e | | |pueda

|Consulta horarios de ineficaz|Ninguna |citas por los pacientes | confirmar su | | |

|media

|Que el paciente |

| |media | |desordenada

|horario de cita.

|GUI personalizada y esta |Prototipos para |

|La interfaz grafica actual es |Ninguna, no

|ordenada

|hecho a medida

del |personalizacin y | | | | |cliente |mejorarla. |

3.5 Alternativas de Competencia

Se ha pensado en realizar un Sistema de Control de Citas a medida de las necesidades, exigencias y futuros intereses que puedan tener los usuarios. De forma que sea convenientes para ambos. Porque hemos vivido la experiencia como cliente, y hemos visto la preocupacin de los usuarios del sistema, por atender y ser atendidos de manera eficiente y rpida. Esa experiencia vivida nos sirve para darnos cuenta de las necesidades primordiales en el sistema a construir y sus futuras implementaciones. La Oftalmolgica tiene como principal inters ver el lado humano del paciente. Actualmente, la Oftalmolgica Asmat tiene en proyecto expandirse captando al sector bajo mediante una sucursal en Pamplona y a largo plazo seguir expandindose y concluyendo metas. La empresa cuenta con un grupo de pacientes que son recomendados por otros, atendidos en la oftalmolgica. No se preocupa mucho por la publicidad ni la

competencia ya que tienen como fortaleza una atencin personalizada y adems un mercado estable.

4. Descripcin del producto

Este sistema tiene como objetivo llegar a satisfacer todos los requerimientos impuestos por usuarios y clientes, logrando as construir un sistema que sea amigable, eficiente, rpido y fcil de usarlo. Contara con una vista para el usuario (secretaria) que le permitir manejar informacin de pacientes ya sea; cdigo, historial, ultima cita registrada, ficha medida, horarios disponibles, datos del paciente, ayuda, etc. Este sistema tambin dispone escaneo por apellido y nombre, en el caso de que el paciente se haya olvidado su cdigo para as tener una bsqueda rpida, posee un acceso restringido a la Base de Datos para poder sacar el historial de paciente. Por ultimo, el paciente tambin podr consultar su horario de cita mediante Internet.

4.1 Perspectiva del Producto

Este sistema busca sustituir al actual sistema, para brindar mejores resultados a la oftalmolgica, reduciendo sus costos, aumentando sus utilidades, mejorando su imagen para as aumentar su mercado.

4.2 Diagrama del Sistema de Contextos

Diagrama del sistema propuesto

[pic]

4.2 Resumen de Capacidades

4.2.1 Costos y Precios

Debido a que es un proyecto realizado por el Grupo GIC software de la FIA se har sin costo alguno en forma directa, solo se tendr los costos de Software (Licencias) y hardware.

4.2.2 Asunciones y Dependencias

Las dependencias siguientes se relacionan con las capacidades del sistema conforme a lo siguiente:

Se asume que el sistema actual continuar funcionando paralelamente al nuevo proyecto.

Se implantar el sistema junto con la base de datos, debido a la estabilidad de esta misma. Para realizar la GUI se realizaran prototipos.

5. Caractersticas del Producto

Esta seccin define y describe las caractersticas SCCOA. Las caractersticas son las capacidades de alto nivel del sistema que son necesarias para entregar ventajas a los usuarios.

5.1 CSW4 Gestionar Citas El Sistema de Gestin de Citas permitir administrar las citas de manera eficiente y ordenada. La gestin de citas ser ejecutada por los usuarios, cada uno de los

cuales tendr opciones diferentes de acuerdo a sus necesidades.

CSW4.1 Determinar Horario de Atencin por Medico Este caso de uso permitir al administrador poder establecer, modificar y asignar el horario de atencin de los mdicos. CSW4.2 Reporte de Pacientes Atendidos Adicionalmente este caso de uso permitir que el Administrador obtenga reportes diarios de los pacientes atendidos en la clnica.

CSW4.3 Consultar Cita Para prestar una mejor atencin a los pacientes, la secretaria podr consultar en el sistema la hora y fecha de la cita asignada del paciente

CSW4.4 Ingresar Descripcin de Cita Este caso de uso permitir a la secretaria ingresar al sistema una breve descripcin de la atencin del paciente en cada cita para as poder tener una historia clnica actualizada.

CSW4.8 Asignar Horario de Cita Este caso de uso permitir asignarle al paciente una cita en la fecha y hora deseada

CSW4.9 Eliminar Cita Este caso de uso permitir a la secretaria cancelar el horario de la cita, en el caso que el paciente no pueda asistir en la fecha asignada inicialmente

CSW4.10 Registrar Cita La cita solicitada por el paciente ser registrada en el

sistema. CSW4.11 Registrar Paciente El sistema permitir registrar y almacenar en la base de datos a todos los pacientes que sean atendidos por primera vez.

CSW4.7 Verificar Horario de Citas Este caso de uso permitir al paciente verificar va Web el horario de su cita.

5.2 CSW7 Gestionar Ficha Clnica El sistema permitir actualizar constantemente los datos del paciente. A travs de esta informacin actualizada el administrador podr realizar un seguimiento al paciente . CSW7.1 Actualizar datos del paciente CSW7.2 Seguimiento del Paciente

6. Otros Requerimientos

6.1 Requerimientos del Sistema

El sistema interconectar con la base de datos, la cual ser desarrollada en Sqlserver2000 o en MSDE dependiendo del anlisis de requerimientos de nuestro software. Se implementara un servidor Web con Apache, Tomcat, que adems servir de Proxy y SMTP para permitir que se pueda tener acceso va Web, se le enviar mail a los pacientes con protocolo SMTP y adems el paciente podr verificar sus citas va Web. La red es LAN. Se utilizaran las computadoras que se encuentran en la empresa, actualizando muchas de ellas.

6.2 Requerimiento de Performance

El servidor debe de estar instalado correctamente para evitar desastres. El sistema proporcionar el acceso rpido, seguro y eficiente a la base de datos de horarios de citas, horario de doctores, entre otros.

6.3 Manual del Usuario

El manual de usuario ser entregado con el software. En el se incluirn todos los procedimientos necesarios para la utilizacin y configuracin del software, as como solucin de problemas (troubleshooting).

6.4 Instalaciones y empaquetado

Se incluir software para fcil instalacin.

6.5 Logotipo del Grupo desarrollador:

[pic]

6.6 Nombre del Producto: SCCOA

6.7 Icono del Producto: [pic]

Anexo 2: Plan de Desarrollo de Software

Plan de Desarrollo de Software Oftalmolgica Asmat

Versin 1.0

Historial de Revisiones

|Fecha tor |01/Abril/2005 |1.0 Arvalo | Asencios | Morales | Polo | Pajuelo | Miranda | | | | | | | | | | | |

|Versin

|Descripcin

|Au

|Ve los aspectos de la fase inicial

|Yanir

|Julissa

|Ivette

|Carla

|Laura

|Harry

Plan de Desarrollo de Software

1. Introduccin

El documento presenta el Plan de Desarrollo de Software para el sistema de Control de Citas de la Oftalmolgica Asmat (SCCOA) elaborado por el grupo GIC Software. Este Plan cubre el trabajo empezado en Marzo 2005 y se espera que el sistema este implementado para Junio del 2005.

2. Propsito

El propsito de este documento es reunir la informacin necesaria para controlar el proyecto y definir el desarrollo de las actividades en trminos de fases e iteraciones requeridas para implementar el sistema de control de citas de la Oftalmolgica Asmat (SCCOA). El plan de Desarrollo de Software detalla la mayora de las actividades, horarios, recursos, hitos y entregables, es decir, presenta la estructura base del sistema, controla la administracin del SCCOA y define los procesos tcnicos y administrativos necesarios para definir los requerimientos del sistema.

Las siguientes personas usarn el Plan de Desarrollo de Software: - El Jefe de Proyecto (Ivette Morales): lo usa para planear horarios y recursos que se necesitan y adems para supervisar el progreso del proyecto. - Miembros del Equipo: lo usan para entender lo que tienen que hacer y que es lo que necesitan hacer y ver de que otras actividades dependen.

3. Alcance

El presente Plan de Desarrollo de Software describe el plan total que utilizar el SCCOA incluyendo el desarrollo del producto. Los detalles de las iteraciones individuales sern descritos en los Planes de Iteracin. Este Plan de desarrollo de software ha sido preparado en base a los requerimientos definidos en el documento de la Visin del SCCOA para proveer direccin y monitorizacin del SCCOA.

4. Definiciones, Acrnimos y Abreviaturas

Ver Glosario

5. Referencias

Plan de Proyecto siguiendo la metodologa RUP (Rational Unified Process). - Manual Oftalmolgica Asmat. - Entrevista con Administrador de Contabilidad, Sr. Dagoberto Camac. - Entrevista a futuros usuarios del SCCOA. - Visin SCCOA

Contenido

El Plan de Desarrollo de Software contiene la siguiente informacin:

|Descripcin del Proyecto del SCCOA. Tambin se | proyecto genere. | |

|Presenta el propsito, alcance, y objetivos

|definen los entregables que se espera que el

|Organizacin del Proyecto del equipo del proyecto. | |Proceso de Administracin define las fases e hitos del | monitorizado. |Planes aplicables de software incluyendo | | | |

|Describe la estructura de la organizacin

|Explica el costo estimado y horario,

|proyecto, y describe como el proyecto ser

|Provee descripcin del proceso de desarrollo

|mtodos, herramientas y tcnicas a

seguir.

6. Descripcin del Proyecto

6.1 Propsito del proyecto, alcance y objetivos

Este sistema tiene como objetivo llegar a satisfacer todos los requerimientos impuestos por usuarios y clientes, logrando as construir un sistema que sea amigable, eficiente, rpido y fcil de usarlo. Asimismo, SCCOA permitir un eficaz control de citas, reduciendo tiempos de espera a travs de fcil y confiable y acceso a los datos, adems de contar con informacin en lnea mediante la cual los pacientes puedan consultar y verificar sus horarios de citas. Se elevar la productividad y eficiencia de trabajo.

6.2 Supuestos y restricciones

- Multiusuario - Sistema seguro: proteccin de informacin, seguridad en las trasmisiones de datos - Adaptacin de normas de seguridad de la empresa: proteccin de datos - Acceso remoto - El sistema deber estar implementado para mediados del 2005

7. Entregables del Proyecto

A continuacin se indican y describen los ms importantes artefactos que sern generados y utilizados por el proyecto y que constituyen los entregables. Esta lista

constituye la configuracin de RUP desde la perspectiva de artefactos, y que proponemos para este proyecto.

1. Visin Este documento define la visin del producto desde la perspectiva del cliente, especificando las necesidades y caractersticas del producto. Constituye una base de acuerdo a los requerimientos del sistema.

2. Plan de Desarrollo del Software Es el presente documento.

3. Lista de Riesgos Para cada riesgo se indica su magnitud, descripcin, impacto, indicadores para monitorizarlo, una estrategia para mitigarlo y el plan de contingencia por si el riesgo se hace real.

4. Modelo de Caso de Negocio Consiste en el contexto del negocio, criterios de xito del proyecto y previsin financiera.

5. Descripcin del Sistema(Resumen Ejecutivo) Describe como se encuentra la empresa para desarrollar el SCCOA

6. Glosario Es un documento que define los principales trminos usados en el proyecto. Permite establecer una terminologa clave del dominio.

7. Modelo de Casos de Uso de Negocio

Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.). Permite situar al sistema en el contexto organizacional haciendo nfasis en los objetivos en este mbito. Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos especficos para este modelo.

8. Modelo de Objetos del Negocio Es un modelo que describe la realizacin de cada caso de uso del negocio, estableciendo los actores internos, la informacin que en trminos generales manipulan y los flujos de trabajo (workflows) asociados al caso de uso del negocio. Para la representacin de este modelo se utilizan Diagramas de Colaboracin (para mostrar actores externos, internos y las entidades (informacin) que manipulan, un Diagrama de Clases para mostrar grficamente las entidades del sistema y sus relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo.

9. Requerimientos de los Stakeholders Para levantar informacin acerca de las necesidades del stakeholder se realiza una serie de entrevistas y encuestas.

10. Plan de Administracin de Requerimientos Se indican y describen los requerimientos.

11. Modelo de Anlisis y Diseo Este modelo establece la realizacin de los casos de uso en clases y pasando desde una representacin en trminos de anlisis (sin incluir aspectos de implementacin) hacia una de diseo (incluyendo una orientacin hacia el entorno de implementacin), de acuerdo al avance del proyecto.

Organizacin del Proyecto Miembros del Proyecto

Roles y Responsabilidades

|Miembro | |Ivette Morales

|Rol

|Responsabilidad

|Analista de Procesos de Negocio|El Jefe del Proyecto

asigna recursos, coordina e interacciona con los | | | |clientes y los usuarios, e intenta

generalmente mantener al equipo de | | correcta. |Yanir Arvalo | | |Analista de los Procesos de | |El Analista de los |proyecto centrado en la meta

Procesos de Negocio es responsable de definir la | |Negocio

|arquitectura del negocio, y de

definir los casos de uso y actores, y | | interactan. |Julissa Asencios | |como ellos | |Diseador de Negocio |El Diseador de

negocio especifica el workflow de los casos de uso del | | | |negocio en trminos de los

trabajadores del negocio y de las entidades | | negocio. |Carla Polo | |de | |Arquitecto de Software |El arquitecto del software

tiene responsabilidad total de conducir las | | | | |software. |decisiones tcnicas principales,

expresada como la arquitectura del | | |

|Ivette Morales

|Diseador de Interfaz de

|Este rol se centra en el

diseo y la "representacin visual que forman"| | utilizada. |Yanir Arvalo |Usuario | |Diseador de Base de Datos |El diseador de la |la interfaz

base de datos es responsable de definir el diseo de| | | | |apremios, disparadores, | |construcciones base de datos|base de datos detallado, incluyendo las

tablas, ndices, opiniones, | |

procedimientos almacenados, y otras | |

especificas necesitadas para almacenar, | | persistentes. |Carla Polo | | |Implementador |Es responsable de |para recuperar, y para suprimir objetos

desarrollar y de probar componentes, de acuerdo con | | para la integracin en | z |Laura Pajuelo | | | | |subsistemas ms grandes. |los estndares adoptados del proyecto,

|Integrador integracin, que ocurre en | | |

|Un integrador es responsable de planear la

|los niveles del subsistema y de | |espacio de trabajo separado de la | |Administrador de Prueba |Organizan la

sistema, con cada uno teniendo un | integracin. |Harry Miranda |

responsabilidad de realizar actividades y de desarrollar | | lgicos. |Ivette Morales | | |Administrador del Proyecto |El papel del encargado |los artefactos en grupos

de proyecto planea, maneja y asigna recursos, | | | | |usuarios, y mantiene a equipo de | |forma prioridades, coordina

interacciones con los clientes y los | proyecto enfocado. |

Entregables y responsabilidades |Descripcin de la Organizacin Morales |Lista de riesgos Asencios |Plan de Riesgos Morales |Plan de iteracin Asencios | | | | |Julissa | | | | |Julissa | | | |Carla Polo ;Ivette | |Julissa |Ivette

|Plan de Desarrollo de Software Asencios

|Monitorizacin del Estado del Proyecto Polo; |Pulir plan de desarrollo de software Polo; |Plan de Iteraciones Pajuelo | |Laura | |

|Carla

|Carla

|Compilar Plan de Desarrollo de Software Pajuelo |Glosario Miranda |Encontrar actores y caso de uso Morales |Arquitectura de Negocio Miranda |Visin de Negocio Morales |Metas de Negocio Morales |Plan de Iteracin Morales |Reglas de Negocio Morales | | | | | | | | |Harry | | |Harry

|Laura

|Ivette

|Carla Polo;Ivette

|Carla Polo;Ivette

|Carla Polo;Ivette

|Carla Polo;Ivette

|Reporte estado monitorizacin y control de Procesos Polo;Ivette Morales |Requerimientos Morales |Glosario | |Carla Polo; Ivette |

|Carla

|Carla Polo;Ivette

Morales |Visin Morales

| |Carla Polo;Ivette | |Yanir

|Plan de Administracin de requerimientos Arvalo |Requerimientos de los Stakeholders Arvalo |Plan de Iteracin |Carla Polo;Ivette Morales |Lista de Riesgos Morales | | | |

|Yanir

|Carla Polo;;Ivette

|Especificaciones Suplementarias Morales |Anlisis y Diseo Morales |Modelo de Anlisis y Diseo Morales |Caso de Uso Morales | | | |

|Carla Polo; Ivette

|Carla Polo;Ivette

|Carla Polo;Ivette

|Carla Polo;Ivette

|Reporte estado monitorizacin y control de Procesos Ivette Morales |Diagramas Secuencia, Colaboracin Arvalo |Prueba Morales |Ideas de Prueba Morales | | | |Carla Polo;Ivette |

|Carla Polo

|Yanir

|Carla Polo;Ivette

|Ambiente Morales |Adquirir herramientas Morales | |

|Carla Polo;Ivette

|Carla Polo;Ivette

|Configuracin y Administracin de Cambios Polo;Ivette Morales |Actualizar requerimientos Morales | |

|Carla

|Carla Polo;Ivette

|Reporte de configuracin de estado Polo;Ivette Morales |Presentacin del Trabajo Final Morales | |Carla Polo;Ivette |

|Carla

Seguimiento y Control del Proyecto

Gestin de Requisitos Los requisitos del sistema son especificados en el artefacto Visin.

Control de Plazos El calendario del proyecto tendr un seguimiento y evaluacin por el jefe de proyecto (Las fechas se encuentran indicadas en el calendario del Proyecto). Para dar seguimiento al desarrollo del proyecto se utiliza la herramienta Microsoft Project 2003, el cual facilita nuestro trabajo.

A continuacin tenemos el Gantt de Seguimiento para el proyecto:

Control de Calidad

Los defectos detectados en las revisiones y formalizados tambin en una Solicitud de Cambio tendrn un seguimiento para asegurar la conformidad respecto de la solucin de dichas deficiencias. Gestin de Configuracin Se realizar una gestin de configuracin para llevar un registro de los entregables generados y sus versiones. Tambin se incluir la gestin de las Solicitudes de Cambio y de las modificaciones que stas produzcan.

Proceso Administrativo

Estimaciones del Proyecto La fase inicial (Inception) de este proyecto tomar 80 das. Debido a que es un proyecto realizado por estudiantes que conforman el grupo desarrollador GIC software de la FIA se har sin costo alguno en forma directa, solo se tendr los costos de Software y hardware. (No calculados a la fecha)

Plan de Proyecto En esta seccin se presenta la organizacin en fases e iteraciones y el calendario del proyecto

Fases del Proyecto

El desarrollo ser conducido usando un enfoque de fases, donde mltiples iteraciones podran ocurrir dentro de una fase. Los hitos que marcan el final de cada fase son mencionados en la siguiente tabla.

|Fase |

|Descripcin

|Inicio

|La fase de Inicio desarrollar los requerimientos del producto y

establecer los casos de uso | | |del negocio. Entre los objetivos de esta primera fase |

encontramos: Establecer el mbito del |

|proyecto y sus lmites, estimar el coste en recursos y tiempo del proyecto y estimar los | |

|riesgos. Se prepara ambiente para el proyecto incluyendo las

herramientas a usar. Al finalizar| | |la fase de inicio se deben tener los siguientes criterios de |

evaluacin: 80% de los |

|requerimientos son modelados con casos de uso y

suficientemente detallado en cuanto a recursos,| | |tiempo y dinero, visin y arquitectura estable, gastos aceptables, |

entendimiento de los |

|requisitos. Si nos se superan los criterios de evaluacin quiz sea

mejor abandonar el proyecto| | |o replanterselo considerablemente. La fase de inicio se |

terminara en Noviembre del 2004. |Elaboracin

|Esta fase analizar los requerimientos y desarrollar el

prototipo de la arquitectura. La idea | | |es proveer una base slida para llevar la carga del esfuerzo de

diseo e implementacin en la | | |fase de construccin. La arquitectura se desarrollar fuera de una |

consideracin de los |

|requisitos ms significativos (sos que tienen un gran impacto en

la arquitectura del sistema) | | |y de una evaluacin de riesgo. La estabilidad de la arquitectura se

evala a travs de unos o | | arquitectnicos. | |ms prototipos | |Al final de esta fase todos los casos de uso habrn completado su

anlisis y diseo. Adems, | | |los casos de uso de alto riesgo habrn sido analizados y

diseados. La definicin del prototipo| | elaboracin. |Construccin |arquitectnico marca el final de la fase de la | |Durante la fase de Construccin, los casos de uso restantes

sern analizados y diseados. Se | | |necesita mayor tiempo en esta fase para

trabajar en el desarrollo del sistema. El hito es un | | functional. |Transicin |lanzamiento de software | |Durante esta fase se harn las pruebas necesarias y ajustes

menores para el lanzamiento de una | | |ultima versin del software. Todo esto es basado en el |

feedback. El hito seria la fecha de | produccin.

|lanzamiento listo para entrar a |

Plan de Iteraciones Los entregables e iteraciones de las fases de elaboracin, construccin y transicin pueden variar.

|Fase

|Conjunto de |Actividades/Artefactos

artefactos|Descripcin

Relacionados|Resultantes |Inicio

| |En el calendario del

|-Administracin del |Define el modelo de

Proyecto punto|Determinar y mostrar | | |Proyecto |negocio, los |4.2.3 observamos cada

entregable de|los requerimientos de | | fase. | del | | | | |usuario. |- Plan de Proyecto |requerimientos del | |producto, el plan |esta

|Desarrollo del alcance | |proyecto y el caso de |Se realizan las pruebas, se

prepara|del proyecto y planes | | y | cambios. | || | | | |viabilidad del proyecto| |desde un |- Modelo de Negocio |negocio |realistas. | | | |Determinar la | |administra |ambiente y se configura

Requerimientos | punto de vista| | negocio. |Elaboracin /Diseo |

|- Anlisis y diseo | | |- Anlisis

|del

|Diseo y anlisis

|- Modelo Anlisis/Diseo

|Asuntos

arquitectnicos| | Datos | tcnicos | | | |completo para todos los|- Modelo de |clarificados. | | |Riesgos

|casos de uso.

| Arquitectura. | los factores |

|- Prototipo |mitigados. | | |

| |

|- Prototipo de

|Anlisis y diseo de |

|Todos

|los casos de uso de

|Se realizan las pruebas, se

prepara|claves desde un punto | | y | arquitectura. |Construccin Interfases de | uso. | | |Usuario | | |revisado por los | | | |usuarios | |alto riesgo |ambiente y se configura

|de vista de usuario y | | | |- Implementacin |Feedback del usuario. | |los casos de |Software totalmente |- Modelo de | |Implementar y testear |- Prototipos de | |administra cambios. |de

Implementacin | | | prepara| | y | cambios. | | |Transicin | | | | | | |

| | | | | | |

|Se realizan las pruebas, se

|ambiente y se configura

|administra

|- Despliegue

|Revisiones menores

|- Modelo de

Despliegue | final. | producto. | prepara| | y | cambios. | | | | | | | |

|Software en Produccin | |finales y lanzamiento |Lanzamiento SCCOA | |final del | | | | | | | | |administra |ambiente y se configura | |Se realizan las pruebas, se

Calendario de Iteraciones

El siguiente cuadro nos muestra las fechas de inicio y fin de las iteraciones que se llevan a cabo durante el proyecto.

Recursos del Proyecto

Plan de Staff

Los individuos integrantes de este proyecto estn organizados como se aprecia en el punto 3.1 del presente documento.

Plan de adquisicin de recursos

Ninguno desarrollado

Supervisin y Control del Proyecto

Plan de Requerimientos

Los requerimientos para el sistema de Control de Citas de la Oftalmolgica Asmat se encuentran en el documento de la Visin. Se desarrollar un Plan de Administracin de Requerimientos.

Plan de control de Entregables

Los entregables debern en lo posible ser terminados en las fechas asignadas, y cada integrante del equipo deber ir completando en lnea sus avances del proyecto. Estos avances sern monitoreados por Jefe del Proyecto semanalmente.

Plan de Administracin de Riesgos

Los riesgos sern identificados en la Fase de Inicio (Inception) usando los pasos del RUP. Debe haber por lo menos un riesgo por cada iteracin que sern evaluados. Se evaluaran los planes de contingencia.

Mtodos, herramientas y tcnicas

Se utilizarn las guas estndar del RUP.

Anexo 3: Arquitectura de Software

SCCOA

Documento de Arquitectura de Software Versin 1.2

Historial de revisiones |Fecha |Versin | |23/03/04 Yanir | Julissa | Ivette | Carla | Pajuelo | | |16/06/04 final |1.2 |SCCOA |Revisin | | | | | | | | | | | | |Laura |Polo | | | |Morales |1.0 | |la Arquitectura de Software |Asencios |Propuesta inicial del documento de|Arvalo |Descripcin |Autores

Documento de Arquitectura de Software

1. Introduccin

1.1

Propsito

Este documento proporciona una descripcin arquitectnica comprensiva del sistema, usando un nmero de diversas vistas arquitectnicas para representar diversos aspectos del sistema. Pensados para capturar y para transportar las decisiones arquitectnicas significativas que se han tomado en el sistema con la finalidad de hacerla una herramienta til y necesaria para el negocio.

1.2

Alcance Este documento de Arquitectura de Software se aplica a SCCOA y sirve

como documento intermediario de comunicacin entre el analista, el arquitecto, los programadores, el que investiga los procesos, casos de uso, etc. y el resto del personal inmerso en el proyecto.

1.3

Definiciones acrnimos y abreviaturas Ver glosario

1.4

Referencias SCCOA Visin 1.0 Glosario RUP (Rational Unified Process) Especificaciones de Caso de Uso Modelo en Racional Rose

2. Representacin Arquitectnica

La Representacin arquitectnica describe cmo est representado el sistema , las vista usadas para visualizarlo. En la Arquitectura del Sistema actual se utilizar las siguientes vistas:

 Modelo del Caso del Uso [Use Case View::Modelo le Caso de Uso]: Describe los procesos que brindarn al negocio la funcionalidad automatizada deseada y cmo funcionan internamente, contiene el modelo de casos de uso. Modelo de Anlisis [Logical View::Modelo de Anlisis]: Describe un primer bosquejo de las clases de anlisis que servirn de soporte para el Diseo. Modelo de la experiencia del usuario [Logical View::Modelo de la experiencia del usuario (UX) ]: Describe las pantallas del sistema, el contenido dinmico de pantallas y como el usuario navega a travs de las pantallas para ejecutar las funcionalidades del sistema. Modelo de Diseo [Logical View::Modelo de Diseo]: Describe las partes arquitectnicos significativas del modelo de diseo, tales como su descomposicin en subsistemas y paquetes.

3. Metas Arquitectnicas y Construccin de la Arquitectura

Los principales objetivos de SCCOA es la automatizacin del proceso de registro de citas, la seguridad y la confidencialidad de la informacin. Adems del registro de los pacientes, la asignacin de horarios de mdicos, la realizacin de consultas y la generacin de reportes.

Todos los requerimientos estipulados en el documento de la Visin 1.0 deben ser tomados en consideracin durante el desarrollo de la arquitectura

La construccin principal del diseo y de la implementacin ha sido que la aplicacin debe funcionar bajo una plataforma que consiste en los componentes siguientes:

1. TomCat 3.2.1 JSP y contenedor de JavaServlet 2. Sql Server o MSDE 3. Web SMTP 4. Redes LAN 5. Router 6. Bastin Host oEDGE FW 4. Vista de Caso de Uso

La funcionalidad del Sistema de Control de Citas se captura en el diagrama de casos de uso (use-case View :Use-Case Model:Global view de actores y casos del uso).

Los casos de uso coloreados de morado son los casos de uso significativos.

Los casos de usos arquitecturalmente-significativos ilustran las funciones dominantes de la mayora de los sistemas de SCCOA y ejercitan todos los componentes importantes del sistema.

Los Casos de Uso restantes se pueden desarrollar rpidamente sin cambios a la arquitectura siguiendo la estructura del uso . Todos los casos de uso implementados tienen un documento asociado de la especificacin del caso de uso. Las referencias a estos documentos se pueden encontrar en la ventana de browser del Rose bajo elementos respectivos del modelo del caso del uso

MODELO DE CASOS DE USO (MCU) [pic] 6. Casos de uso arquitectnicamente significantes

Los casos de uso Arquitecturalmente -Significativos son aquellos que representan las partes ms crticas de la arquitectura del sistema y demuestran la funcionalidad del sistema . Adems de lo ya mencionado, para SCCOA los casos de uso significativos han sido priorizados en base al soporte que brindan a las metas del negocio (Clnica). Los ms significantes son:

Registrar Cita; demuestra cmo se asignan procesan y registran las citas. Registrar Paciente; demuestra cmo se realiza el registro de los pacientes, como requisito indispensable para los pacientes que acuden a solicitar una cita por primera vez. Eliminar cita; demuestra cmo el sistema permite cancelar eliminar una cita asignada a un paciente. Asignar horario de cita ; demuestra cmo se asignan los horarios de la citas segn la eleccin del paciente. Actualizar datos del paciente, permite mantener actualizados los datos personales y familiares de los pacientes. Determinar Horario de Atencin por Medico; demuestra cmo son determinados los horarios de atencin de los mdicos. Verificar Horario de Cita; demuestra cmo el sistema permite a los pacientes verificar el da y hora de su cita (via Web). stos se demuestran y se describen brevemente abajo.

Casos de Uso Significativos [pic] Breve descripcin:

Registrar Cita, Este caso de uso permite a la secretaria registrar una cita del

paciente. El paciente solicita una cita, la secretaria procede a buscar al paciente en la Base de Datos , si el paciente ya est registrado se procede a asignarle un mdico y el horario de la cita. Si el paciente es nuevo, es decir que an no est registrado se tendr que registrarlo. Registrar paciente, si el paciente acude por primera vez a solicitar una cita se tendr que registrar. Asi, el paciente proporcionar sus datos personales y la secretaria proceder a registrarlo y el sistema generar su ficha clnica (esta ficha clnica tendr un nmero de ficha el cual ser generado aleatoriamente). Eliminar cita, este caso de uso permitir a la secretaria cancelar o modificar el horario de una cita. Asignar horario cita, este caso de uso permite a la secretaria asignar los horarios de citas solicitados por los pacientes una vez que ste haya sido registrado. El paciente podr elegir el da, semana y mes de la cita. La fecha elegida por el paciente ser asignada slo si dicha hora y da est disponible con el doctor elegido.

Actualizar Datos del paciente, Este caso de uso describe los procedimientos que debe seguir la Secretaria para actualizar los datos personales y familiares del paciente. Determinar Horario de Atencin por Medico, Este caso de uso permite al Usuario (Administrador) asignar el horario de atencin de los mdicos; para ello deber ingresar los horarios disponibles y determinados por los propios doctores. Verificar horario de cita, El paciente podr tener acceso al sistema para realizar consultas sobre fecha y hora de cita y as verificar su cita. Todo usuario deber ingresar id y password el cual ser enviado a su mail, utilizando un SMTP (Simple Mail Transfer Protocol).

5. Vista Lgica

Esta seccin describe la estructura lgica del sistema. Empieza con la descripcin de la arquitectura y despus presenta sus elementos estructurales y del comportamiento dominantes.

1. Elementos Modelo Arquitecturalmente-significativo

5.1.1 Componentes del Negocio El Sistema de Control de Citas se ha descompuesto en tres componentes : Gestin de citas, Gestin de Ficha Clnica y servicios comunes. Cada uno de los componentes del negocio se divide ms a fondo en tres capas: (1) Lgica de la presentacin (2) Lgica del Negocio y (3) Lgica de la Integracin. Es decir la Arquitectura descompone los sistemas a lo largo de 2 dimensiones

1. La primera dimensin est a lo largo de las lneas de la funcionalidad del sistema 2. La segunda dimensin est a lo largo de las capas comnmente reconocidas que separan tres clases de preocupaciones a. Preocupaciones de la presentacin, o cmo manejar la comunicacin con el usuario y controlar su acceso a los servicios y a los recursos de sistema b. Preocupaciones de negocio, o cmo organizar los elementos del sistema que realizan funciones de los servicios del negocio y de sistema, y c. Preocupaciones de la integracin, o cmo conectar los elementos del sistema con el mecanismo de la persistencia, otros sistemas, los dispositivos fsicos, el etc.

El resultado es a matriz-como la estructura del sistema donde cada elemento del diseo pertenece a un componente del negocio (o a los elementos y el

componente comunes del servicio) y a una capa dentro de este componente/servicio.

[pic]

1) Gestin de citas , este componente es el responsable de todos los aspectos relacionados con la administracin de las citas. En detalle, los elementos de este componente del negocio colaboran para realizar los casos de uso : Registro de citas, Registro del paciente, Asignar Horario de cita, Determinar horario de atencin por mdico, Eliminar cita, Ingresar descripcin de citas, Reporte de pacientes atendidos y Verificar Horario de citas 2) Gestin de Ficha clnica, este componente es el responsable la verificacin y Actualizar datos del paciente 1. Modelo de experiencia del usuario

Ver anexo 15

6.Realizaciones de casos de uso arquitectnicamente significativos Las realizaciones de Casos de Uso del Sistema se especifican con su respectiva documentacin en el Anexo 12.

7. Vista de Despliegue

La vista del despliegue de un sistema muestra los nodos fsicos sobre los cuales el sistema ejecuta y la asignacin del sistema procesado a los nodos. El uso de referencia en el Sistema de Control de Citas Oftalmolgica Asmat puede ser desplegado sobre

configuraciones de hardware diferentes. [pic]

6. Calidad

Se propone que el sistema cuente con un control eficaz de las citas y el manejo de una base de datos que permita manipular ordenadamente la informacin, que sea libre de errores y dispuesto a cambios para aumentar la productividad, reduzca tiempos de espera, satisfaga a los operadores del sistema y mejore la imagen de la oftalmolgica.

Anexo 4: Glosario

11

Sistema de Control de Citas Oftalmolgica Asmat Glosario Versin 1.0

Historial de Versiones

|Fecha | |23/03/05 Yanir | Julissa | | |

|Versin

|Descripcin

|Autor

|1.0 |

|Versin preliminar del |Arevalo Salvador,

|glosario. | |

|Asencios Cerna,

|Morales Henderson,

Ivette | Melita | Janett | | | | | | | | | | | |

| |Polo Gonzales, Carla

|Pajuelo Grandez, Laura

| |

| |

Glosario

1. Introduccin

El presente documento ser una recopilacin de terminologa utilizada el los documentos presentada de forma ordenada con explicaciones de fcil entendimiento que harn llevadera la lectura de los mismos. Se trata de un diccionario informal de datos y definiciones de la nomenclatura que se maneja, de tal modo que se crea un estndar para todo el proyecto.

2. Propsito

El propsito de este glosario es definir con exactitud y sin ambigedad la terminologa manejada en el proyecto de desarrollo de un sistema de control de citas Asmat (SCCOA). Tambin sirve como gua de consulta para la clarificacin de los puntos conflictivos o poco esclarecedores del proyecto.

3. Alcance

El alcance del presente glosario es extensible a todo el proyecto SCCOA pues busca la mejor interpretacin de todo aquel que lea el proyecto.

4. Organizacin Glosario

El presente documento est organizado por definiciones de trminos ordenados de forma ascendente segn la ordenacin alfabtica tradicional del Espaol.

5. Referencias

- Documento Plan de Desarrollo Software del Proyecto SCCOA

- Documento Visin

- Documentos de Especificacin de Casos de Uso SCCOA

13

6. Definiciones

rea El organigrama de la empresa muestra tres reas:

rea Administrativa Se encarga de la administracin de cada rea de la Oftalmolgica y de supervisar los concesionarios.

rea Contable

Es la responsable de los financiamientos, toma en cuenta los factores monetarios importantes decidir.

rea Mdica Comprende mdicos y enfermeras. Se encarga de resolver y aliviar los problemas Oftalmolgicos con los que el paciente llega.

Atencin Personalizada Es la atencin que se brinda dedicadamente a los pacientes ya sean nuevos o regulares.

Cancelacin de Citas Es la accin que hace el paciente o doctor por motivos ajenos teniendo as que reajustar una nueva citacin en la Oftalmolgica.

Cita Es la coordinacin del da y hora disponible a efectuarse una atencin del paciente. Tipos de cita: ciruga, examen y consulta

Dominio Son las clases relevantes del sistema, en la cual van a estar las tablas de los datos, para luego poder usarlas.

Entregables Son documentos que proporcionan la entrada y la salida para las actividades, y el mecanismo por el cual la informacin es transmitida entre las actividades.

Feedback

Retroalimentacin.

Ficha Clnica Documento en donde se encuentran los datos del paciente, datos del familiar o tercero a cargo y las indicaciones del doctor.

Hito Representa un evento o condicin que marca la finalizacin de un grupo de tareas relacionadas a la finalizacin de una fase del proyecto, a partir del cual se toman decisiones.

Iteracin

Ciclo de desarrollo completo dando como resultado una entrega de producto ejecutable (interna o externa)

Paciente Persona que solicita servicio oftalmolgico.

Paciente Nuevo Son los pacientes que van por primera vez a la Oftalmolgica y que son registrados como nuevos para el sistema.

Paciente Regular Son pacientes que ya fueron registrados por el sistema, su informacin esta ubicada en la Base de Datos.

Registro en el sistema

Cada vez que el usuario accede al sistema deber registrarse en el mismo haciendo uso de un nombre de usuario y una contrasea asociada al mismo. Estos datos sern los que figuraran en la Base de Datos y en el sistema si son o no correctos, ofreciendo una funcionalidad determinada segn el tipo de usuario que se haya registrado.

Reporte de Citas Es el registro de las citas efectuadas cada cierto tiempo, generalmente son impresas y distribuidas a los vigilantes y doctores.

Sector El paciente pertenece a un tipo de sectores

Sector Alto Es un grupo de personas que cuenta con suficientes recursos que satisfacen sus necesidades.

Sector Bajo Personas con recursos bajos.

Sector Medio Grupo de personas de medianos recursos

SCCOA Sistema de Control de Citas de la Oftalmolgica Asmat.

Tipos de clientes

Es la diferenciacin que se hace a los clientes, diferencindolos por clientes regulares y nuevos.

Usuario del Sistema Son las personas encargadas de manipular el sistema, ingresando la data de los pacientes.

Vaciar Citas Es la accin que realiza la secretaria cuando pasa los datos a la mquina.

Anexo 5: Lista de Riesgos

SCCOA Lista de Riesgos Versin 1.1 Historial de Revisiones

|Fecha | |23/03/05 Inicio.|Arvalo Yanir | Julissa | Ivette | Carla | | |

|Versin

|Descripcin

|Autor

|1.0

|Riesgos identificados al comienzo de la fase de

| | | | | | | |Polo |Morales |Asencios

| Pajuelo |22/04/05 tanto | Julissa | Ivette | Carla | Pajuelo

| | |2.0

|Laura

|Nuestros requerimientos han aumentado y por | |Asencios

|Arvalo Yanir | | | | | | | | | | |

|nuestros riesgos

|Morales

|Polo

|Laura

|Magnitud del Riesgo Impacto | | |8 |

|Descripcin e |Estrategia de Mitigacin y/o Plan de |

|Contingencia

|No satisfacer los requerimientos establecidos por los | |stakeholder,

usuarios|Tener una conversacin abierta con el | |del sistema.

delimitando los requisitos a| | | |8 el | es |Que al presentar al Stakeholder o tomador de decisiones |No encontrada. Los prototipos se realizan| |prototipo, y ste acepta, el equipo de programacin no |por el mismo equipo | |alcanzar.

de programacin que | | prototipos. | | |8 |No cumplir con el periodo de tiempo establecido para terminar | |establecido |capaz de realizar lo especificado en los |trata de especificar lo que se pueda | | |programar.

|Cumplir el cronograma de desarrollo | en la fase inicial del | |

|el software (SCOOA). |

|proyecto, dndole

preferencia a lo que va| | empresa. |8 | |Si se diera el caso de que uno de los integrantes del | |ser entregado para la

equipo |Se tendra que estudiar la manera para | | |GIC, se enfermara o padeciera de algo. |hace

una nueva redistribucin de tareas. | |7 nuestra | |Si se diera el caso que la empresa no aceptara |Se tendra que explicar y exponer su |

|propuesta econmica, en lo que se refiere a implementacin

de |requerimiento para el sistema. En el caso| | |nueva tecnologa (Servidores, PCs, etc.) |de que

no se pudiese llevar a cabo una | | buscara equipos | | | |7 |Contina deteccin de errores por los | |sustitutos. | |previa explicacin, se

usuarios. | poder analizar su |

|Tener un mantenimiento del sistema cada | | | | |evolucin. | |cierto tiempo, para

|7 de |

|Que el equipo GIC no domine en su totalidad el lenguaje |Capacitaciones y cursos sobre lenguajes | |programacin a usar. El equipo de desarrollo es inexperto el |

|de Programacin, RUP, entre otros. | orientadas | | |6 sistema existe un | | |objeto.

|proceso unificado racional (RUP) y las tcnicas | |

|Dificultad del usuario |

|En nuestro

|cuando interactan con software, ocasionando perdida de | |instruye al

tiempo|periodo de prueba en el cual se le | |en la empresa.

usuario a cerca del software,| | | |ensendole el

procedimiento adecuado | | solucin. |6 | | | Perdida de informacin por causa de cada de electricidad en |para la

|Se contara con un registro de backup, el | | ltimos riesgos | | |la empresa. | |efectuados. |cual tendr los

LISTA DE RIESGOS El riesgo del proyecto es evaluado al menos una vez por iteracin y documentado en esta tabla. Los riesgos de mayor magnitud son listados primero. a escala de magnitud de riesgo1-10

|6 empresa. |

|Incompatibilidad con otros sistemas de la |Se creara un Sistema que sea compatible | | |con

las reas de la empresa mejorando as| | entre cada rea. | |6 el | |Que los miembros del equipo de desarrollo GIC no tengan |Se debe hacer un seguimiento del proyecto| |tiempo suficiente para continuar el proyecto debido a los | |y | |el flujo de informacin

cumplir con las tareas. Debe haber | profesionales. |5 software | 2003. | | |6

|exmenes, estudios y/o prcticas pre|buena coordinacin. |

|Atraso en tareas debido a problemas de hardware y |En caso de que ocurra se realizaran los | |como problemas con la instalacin del Rational Suite |trabajos utilizando las maquinas de la | | |universidad.

|Que no nos puedan proporcionar la informacin necesaria en |

la |Llamar antes de hacer la visita a la |

|Oftalmolgica debido a que no tengamos permiso o no

se | Camac) |5 no |

|Oftalmolgica.

|encuentra el jefe (Sr. Dagoberto | |

|Si se diera el caso de que los pacientes o usuarios |Se le enviara una gua detallada de los | |supieran como utilizar la pagina Web. |pasos a

seguir, va e-mail a todos los | | | | | |En el caso que los | |pacientes.

pacientes no tengan | | | |e-mail, se les

entregara una gua junto a| | | |la cita solicitada. |

Anexo 6: Modelo de Caso de Uso de Negocio

[pic]

Anexo 7: Especificacin de Casos de Uso de Negocio

Sistema Control de Citas Oftalmolgica Asmat Especificacin de Caso de Uso de Negocio: Generar Reportes

Versin 1.0

Historial de Versiones

|Fecha | |15/04/05 Salvador, Yanir | Cerna, Julissa | | |

|Versin

|Descripcin

|Autor

|1.0 |

|Propuesta Inicial del Caso de Uso de |Arevalo

|Negocio en base a las observaciones |Asencios | |realizadas al modelo del negocio. | | |Polo Gonzales, Carla |Morales

Henderson, Ivette | Melita | Janett | | | | | | | | | | | | |

|Pajuelo Grandez, Laura

1. Generar Reporte

1. Introduccin

1. Propsito

Este documento proporciona la descripcin, propsito, definicin, abreviaturas y referencias, necesarios para el desarrollo del caso de uso de negocio: Generar Reporte

1. Alcance

Este documento contiene las propiedades del caso de uso de negocio, como se desarrolla, el flujo de actividades, que nos servirn como base para el modelado del caso de uso del sistemas que abarque estas actividades de una manera mas rpida y confiable.

2. Definiciones, Acrnimos y Abreviaciones

Ver Glosario.

3. Referencias

- Glosario. - RUP (Rational Unified Process) - Listas impresas - Documento: Requerimientos del Stakeholder

1. Descripcin

Este caso del uso describe como se realiza el proceso de generacin de reportes, que es un documento impreso que sirve para que todos los involucrados en la atencin previa de una cita (Secretaria, Enfermera, Personal de Seguridad) tengan conocimiento de quienes son los pacientes que se atendern en una fecha determinada y puedan brindar la atencin necesaria de acuerdo a los requerimientos del tipo de cita. Los reportes se realizan diariamente.

2. Metas

Este caso debe lograr una mejora la comunicacin entre todos los responsables, que les permita brindar una mejor atencin al paciente, siempre en funcin a los requerimientos del tipo de cita solicitada

3. Workflow

1. La secretaria realiza una consulta de las citas que sern atendidas en la fecha requerida 2. Elabora un reporte (3 copias) que incluye datos del paciente (Nombre, Apellidos), medico que lo atender, hora de la cita, tipo de cita. 3. Una copia esa entregada al personal de enfermera, para que realice los acondicionamientos necesarios de acuerdo al tipo de cita (por ejemplo: Ciruga) 4. Otra copia es entregada al personal de Seguridad, para que lleve un control de las personas que ingresan a la clnica. 5. La otra copia es para la secretaria, para que realice la verificacin de las citas que sern atendidas y que los acondicionamientos han sido realizados.

4. Precondiciones Deben haber citas registradas para el DIA solicitado

5. Poscondiciones Con la generacin de los reportes, se lleva un control de las personas que ingresan a la clnica y de los que son atendidos

6. Categora

El caso de uso es bsico operativo

7. Riesgos

De no realizarse este caso de uso de negocio, no habra un control de las citas que sern atendidas y sobre todo podran ocurrir problemas en el acondicionamiento necesario para la atencin de las citas, segn sea el tipo solicitado.

8. Posibilidades

Que exista un reporte en base a la informacin ingresada al momento de registrar la cita.

9. Dueo del Proceso

La secretaria, es la encargada de realizar los reportes y de imprimirlas.

10. Requerimientos Especiales

La secretaria necesita de una impresora, para poder imprimir los reportes generados

[pic]

Sistema Control de Citas Oftalmolgica Asmat Especificacin de Caso de Uso de Negocio:

Llenar Ficha clnica

Versin 1.0

Historial de Versiones

|Fecha | |15/04/05 Salvador, Yanir | Cerna, Julissa | | |

|Versin

|Descripcin

|Autor

|1.0 |

|Propuesta Inicial del Caso de |Arvalo

|Uso de Negocio en base a las |Asencios | |observaciones realizadas al |Morales | |modelo del negocio. | |Polo Gonzales,

Henderson, Ivette | Carla Melita | Janett | | | | | | | | |

|Pajuelo Grndez, Laura

Procesar listas

1. Introduccin

1. Propsito

Este documento proporciona la descripcin, propsito, definicin, abreviaturas y referencias del caso de uso de negocio: Llenar Ficha Clnica.

2. Alcance

Este documento servir como base, para la identificacin de un proceso del negocio que aunque parece muy simple, tiene gran relevancia en la clnica Llenar ficha de datos y su posterior automatizacin que ayudara a que el servicio brindado sea mas rpido y confiable.

3. Definiciones, Acrnimos y Abreviaciones

Ver Glosario.

4. Referencias

- Glosario. - RUP (Rational Unified Process) - Documento: Requerimientos del Stakeholder - Fichas clnicas actuales de la clnica

11. Descripcin

Este caso del uso describe como se realiza el proceso de llenado de la ficha clnica, que es responsabilidad del Medico, con todos los datos necesario acerca del tratamiento brindado; que luego ser anexado a la historia clnica del paciente.

12. Metas

Este caso de uso cubre la meta de mejorar el seguimiento que se realiza del tratamiento brindado a cada paciente.

13. Workflow

Luego que el medico realiza el tratamiento al paciente 1. El medico procede a registrar en la ficha clnica, la siguiente informacin: o Tratamiento brindado o Si se realizo algn examen especial: tipo o Diagnostico o Si se le receto algn tipo de medicina o Alguna observacin y/o comentario que considere importante 2. La ficha es entregada a la secretaria para que la archive y la anexe a la historia clnica del paciente.

14. Precondiciones Que el paciente haya recibido el tratamiento y que cuente con una ficha en blanco creada al momento de su gestin de cita

15. Postcondiciones El paciente contara con una historia clnica, conformada por las fichas generadas en cada cita, con toda la informacin importante en referencia a su tratamiento.

16. Categora

El caso de uso es bsico operativo

17. Riesgos

De no realizarse este caso de uso de negocio, no podra contarse con informacin importante del paciente, acerca de otros tratamientos recibidos.

18. Posibilidades

Podra implementarse una manera mas rpida, confiable y completa: contando con una base de datos que permita registrar toda la informacin acerca del tratamiento y que permitir al medico tener acceso a ella mas rpido sin tener que recurrir al material impreso archivado por la secretaria.

19. Dueo del Proceso

El medico es el responsable del llenado de la ficha, segn su diagnostico y la secretaria es la encargada de archivarla.

20. Requerimientos Especiales

Los requerimientos para el archivado de la ficha es que exista o se cree una historia clnica, que estar conformada todas las fichas de tratamiento del paciente

[pic]

Control de Citas Oftalmolgica Asmat Especificacin de Caso de Uso de Negocio:

Gestionar Cita

Versin 1.1

Historial de Versiones

|Fecha |Descripcin |23/03/05

|Versin |Autor |1.0 | |Uso de Negocio: Cancelar Citas | | |Morales Henderson, | |Propuesta Inicial del Caso

de |Arvalo Salvador, Yanir | |

|Asencios Cerna, Julissa | Ivette | Melita | Laura Janett |15/04/05 | | | |1.1. | | |

|Polo Gonzales, Carla

|Pajuelo Grndez,

|Caso de uso de Negocio, | |de las modificaciones |Asencios

despus|Arvalo Salvador, Yanir | Cerna, Julissa | Henderson, Ivette | | | | | | | |

|realizadas en funcin a las

|Morales

|observaciones a la versin 1.0 |Polo

Gonzales, Carla Melita | Laura Janett | |

|Pajuelo Grndez,

Gestionar Citas

1. Introduccin

1. Propsito

Describir el Caso de Uso del proceso de negocio: Gestionar Cita para evaluar como se realizar su automatizacin

2. Alcance

Este documento servir de base para poder realizar un correcto modelamiento del proceso de la clnica, su situacin actual y poder manejarlo con facilidad para la puesta en marcha del sistema propuesto.

3. Definiciones, Acrnimos y Abreviaciones

Ver Glosario.

4. Referencias Glosario. RUP (Rational Unified Process) Listas impresas Documente: Requerimientos del Stakeholder

1. Descripcin

El documento describe los procedimientos para la gestin de las citas en la Oftalmolgica Asmat.

2. Metas

Que el proceso cumpla con las expectativas, producto del proceso de expansin de la clnica, lo cual conduce a la satisfaccin del cliente.

3. Workflow

4.1 Workflow Bsico

3. Paciente solicita cita a la secretaria 4. La secretaria solicita datos personales 5. El paciente se identifica con su nombre y apellido 6. El paciente indica el mdico con el que desea ser atendido 7. Secretaria consulta el horario disponible del mdico y se los comunica al paciente 8. Si encuentra el horario deseado, el paciente selecciona el horario de la cita 9. Secretaria asigna el horario elegido y lo registra en un cuaderno de citas. 10. Al finalizar el da laboral, la informacin registrada en el cuaderno de citas es registrada en una base de datos en ACCESS.

4.2 Workflow alternativo: Mdico no disponible en el horario deseado por el paciente 1. Si luego del paso 5, el paciente no acepta el horario propuesto, el flujo regresa al paso 4 del flujo normal

4. Precondiciones:

5.1 El paciente esta inscrito en la base de Datos de la Clnica y por lo tanto tiene una ficha clnica. 5.2 La secretaria debe tener un registro de los horarios disponibles para cada mdico

5. Poscondiciones:

6.1. La cita queda registrada en un cuaderno de citas 6.2 Todas las citas sern registradas en la base de datos de la clnica, al finalizar el da

6. Categora

El caso de uso es bsico operativo

7. Riesgos

EL principal riesgo de este proceso, es que al no existir una base de datos actualizada en cada instante, existe la posibilidad de error al momentote dar un horario como disponible.

8. Posibilidades

Que la secretaria puede tener acceso rpido a los datos de pacientes ya inscritos.

 Que la secretaria pueda gestionar una cita, teniendo informacin actualizada al momento, acerca de los horarios disponibles para cada medico.

9. Dueo del Proceso

La secretaria, va hacer la encargada de gestionar las citas.

10. Requerimientos Especiales

Los requerimientos especiales de este caso de uso son: La interaccin del paciente y la secretaria. [pic]

Sistema Control de Citas Oftalmolgica Asmat Especificacin de Caso de Uso de Negocio: Inscribir Paciente

Versin 1.1

Historial de Versiones

|Fecha

|Versin |

|Descripcin

|Autor

|23/03/05

|1.0

|Propuesta Inicial del Caso de Uso de | |Asencios Cerna,

Negocio |Arvalo Salvador, Yanir | | |

Julissa | Ivette | Melita | Laura |15/04/05 las | las | | | | | |

| | |Morales Henderson,

|Polo Gonzales, Carla

| | |1.1

|Pajuelo Grndez,

|Caso de uso de Negocio, despus de |

|Arvalo Salvador, Yanir |

|modificaciones realizadas en funcin a | |Morales

|Asencios Cerna, Julissa | | |

|observaciones a la versin 1.0

Henderson, Ivette | Melita | Laura | | | |

|Polo Gonzales, Carla

|Pajuelo Grndez,

Registrar Paciente

1. Introduccin

1. Propsito

Describir el Caso de Uso del proceso de negocio: Inscribir Paciente actual para poder analizarlo y elaborar el modelado del sistema

2. Alcance

Este documento servir de base para identificar como se desarrollan los procesos actuales de la clnica, poder realizar un correcto modelamiento y poder manejarlo con facilidad para la puesta en marcha del sistema propuesto.

3. Definiciones, Acrnimos y Abreviaciones

Ver Glosario.

4. Referencias

21. Descripcin

Este Caso de Uso del Negocio se lleva a cabo cuando un nuevo paciente solicita una cita, para lo cual se debe inscribir previamente.

22. Metas

Este caso de uso de negocio cubre las metas de satisfaccin del cliente y expansin del negocio.

23. Workflow

La Secretaria entrega ficha de datos al paciente. El Paciente llena ficha con los siguiente datos personales: o Nombres o Apellido Paterno o Apellido Materno

o Fecha de Nacimiento o Edad o Estado civil o Telfono o Documento de identidad o Domicilio o Direccin de correo electrnico

Y los siguientes datos familiares: o Familiar o Domicilio o Referido o Telfono familiar La secretaria recibe la ficha y llena la siguiente informacin: o Fecha de registro o Numero de historia Con esta ficha, el cliente queda registrado

24. Precondiciones Que el paciente proporcione todos los datos solicitados

25. Poscondiciones El paciente quedara registrado en la clnica y sus datos estarn ya disponibles, para una probable prxima cita

26. Categora

El caso de uso es bsico operativo

27. Riesgos

Al ser un proceso manual, tanto en el llenado como en el archivo: La informacin corre mas riesgo de extraviarse Un proceso de validacin de clientes ya inscritos, es ineficiente, ya que se debera revisar cada hoja del cuaderno para verificar la existencia o no de ese cliente.

28. Posibilidades

El Caso de Uso registrar paciente, podra tener una ventana aporte para el inscribir al paciente que previamente realice una validacin de la existencia o no de ese paciente.

29. Dueo del Proceso

El dueo del proceso es la secretaria que es la autorizada para inscribir pacientes

30. Requerimientos Especiales Que se pueda validar si el paciente ya se encuentra registrado.

Anexo 8: Modelo de Objetos de Negocio

Modelo de Objetos del Negocio [pic]

Anexo 9: Modelo Conceptual y Lgico

MODELO CONCEPTUAL

[pic]

MODELO LGICO

[pic]

Anexo 10: Priorizacin de los Casos de Uso

PRIORIZACION DE LOS CASOS DE USO

Este documento proporciona en detalle, la jerarqua de los casos de usos dependiendo del grado de complejidad que estos presentan, cabe resaltar que para priorizar dichos casos de uso hemos relacionado las Metas del Negocio con los Casos de Uso del Sistema, as los Casos de Uso que estn relacionados con ms metas del negocio sern los ms prioritarios. Cabe resaltar que el nmero de priorizacin est referido al nmero de metas de negocio que estn relacionadas al Caso de uso (nmero de lneas)

|CASO DE USO SCRIPCION |Registrar Cita de uso describe los | |6 |PRIORIZACION | |Diaria |Este caso |FRECUENCIA |DE

| que debe seguir la | Registrar una Cita. | |Registrar Paciente

| | |

|procedimientos

|Secretaria para

|5 | |

|Diaria

|Este

caso de uso describe los | que debe seguir la | | | |

|procedimientos

|Secretaria para

Registrar un nuevo | | | | |Paciente.(este

registro generar una | | | |Eliminar Cita uso describe los | que debe seguir la | actualizar una cita. | | se refiere a la | | cita. | | | |cancelacin de la | | |Esta actualizacin | | | | |Secretaria para |3 | | |procedimientos |Semanalmente |Este caso de | | |Ficha Clnica)

|Asignar Horario de Cita |3 | |Semanalmente |Este caso de uso

describe los

| que debe seguir la | asignar el horario de| | Paciente, |

| | |

|procedimientos

|Secretaria para

|cita para un

|Actualizar Datos del paciente |3 | | | | | |Secretaria para | |procedimientos |Mensualmente |Este caso de uso

describe los |

que debe seguir la | actualizar los datos | | paciente.

| |

|del

|Reporte de Pacientes Atendidos |2 Mensual | que debe seguir el | | reporte | | atendidos | | | | |Este caso de uso describe los | | |

|Semanal | |procedimientos

|Supervisor para obtener un

|de los pacientes

|Determinar Horario de Atencin |2 describe los |por | |Semanalmente |Este caso de uso

Mdico que debe seguir el |

| | |

|procedimientos

|Paciente para

verificar su horario de| | El paciente podr| | | | |efectuar esta | | |cita en el sistema.

consulta va Web desde| | encuentre. | |2 | | |procedimientos |Diaria |Este | | |el lugar donde se

|Verificar Horario de Cita caso de uso describe los | que debe seguir el | | | |

|Paciente para

verificar su horario de| | El paciente podr| | | | |efectuar esta | | |cita en el sistema.

consulta va Web desde| | encuentre. |Consultar Cita caso de uso describe los | | | |1 | | | |Secretaria para |Diaria |Este | | |el lugar donde se

|procedimientos que debe seguir la | consultar una cita. | | |

|Ingresar Descripcin de Cita los | que debe seguir el | Actualizar la Ficha | | | | |ste es atendido. |1 | | | | | | |Clnica del | |Doctor para | |procedimientos |Diaria |Este caso de uso describe

paciente cada vez que | El doctor | Ficha una breve | atencin del | | | | | | | | |

|registrar en la

|descripcin de la

|paciente.

|Seguimiento del Paciente Mensual | que debe seguir el | realizar un | los pacientes | | |

|1

|Semanal | |procedimientos

|Este caso de uso describe los | | | | |

|Supervisor para

|seguimiento de

Priorizacin de casos de uso

[pic]

Anexo 11: Modelo Casos de Uso del Sistema

MODELO DE CASOS DE USO [pic]

Anexo 12: Especificaciones de Caso de Uso

SCCOA Especificacin de Caso de Uso: Registrar Paciente

Versin 1.1

Historial de Revisiones

|Fecha |Versin | |19/04/05 Uso de | Asencios | Pajuelo |04/06/05 Final | |1.1 |Revisin |SCCOA | | | | |Laura |1.0 |Yanir Arvalo | |Descripcin de la Especificacin de Caso de | |Registrar Paciente. |Julissa |Descripcin |Autor

Especificacin de Caso de Uso: Registrar Paciente

1. Nombre: Registrar Paciente

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir la Secretaria para Registrar un nuevo Paciente (este registro generar una Ficha Clnica)

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando la Secretaria solicita al Sistema Registrar un Paciente.

3.1 Flujo Bsico 1. El Sistema muestra el Formulario de Registro de Paciente. 2. La Secretaria ingresa datos personales del paciente (nombres, apellidos, nmero de documento, domicilio, distrito, provincia, telfono, fecha de nacimiento, estado civil, e-mail). 3. La Secretaria ingresa datos del familiar del paciente (nombre, apellido, parentesco, nmero de documento, domicilio y telfono) 4. La Secretaria solicita generar Ficha Clnica. 5. El sistema graba Ficha clnica. 6. El sistema muestra un mensaje Ficha Clnica grabada satisfactoriamente 7. La secretaria solicita imprimir una constancia de registro de usuario y password. 8. El sistema emite constancia de registro de usuario y password y el caso de

uso finaliza

3.2. Flujos Alternativos

3.2.1. Datos obligatorios no ingresados En el punto 4, si entre los datos personales del paciente a excepcin del e-mail no han sido ingresados, el sistema mostrara el mensaje llenar todos los campos obligatorios solicitados. Y el caso de uso contina en el punto 2.

3.2.2 Enviar Mail En el punto 2, si la Secretaria ingresa e-mail del paciente. La secretaria elige Opcin enviar e-mail El sistema enva correo electrnico de confirmacin de usuario y password. El sistema muestra un mensaje "mail enviado satisfactoriamente"

4. Requerimientos Especiales Tener una impresora conectada al terminal de la Secretaria. Contar con formularios de Constancia de Confirmacin de usuario y password.

5. Pre condiciones Paciente No Registrado

Un Paciente no debe estar registrado en el sistema (nuevo paciente).

6. Post condiciones Paciente Registrado El Paciente queda registrado en el sistema.

7. Puntos de Extensin Ninguno.

SCCOA Especificacin de Caso de Uso: Actualizar Datos del Paciente

Versin 1.1

Historial de Revisiones

|Fecha tor |19/04/05 Uso de | Paciente. | Pajuelo |04/06/05 Final | | |

|Versin

|Descripcin

|Au

|1.0 |Yanir Arvalo |

|Descripcin de la Especificacin de Caso de | |Actualizar Datos del

|Julissa Asencios |

| |Laura

|1.1

|Revisin |SCCOA |

Especificacin de Caso de Uso: Actualizar Datos del Paciente

1. Nombre: Actualizar Datos del Paciente

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir la Secretaria para Actualizar los datos de un paciente.

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando la Secretaria solicita al Sistema Actualizar Datos del Paciente.

3.1 Flujo Bsico 1. El Sistema muestra el Formulario de Actualizar Datos del Paciente 2. La Secretaria solicita buscar paciente. 3. El sistema muestra datos del paciente y del familiar. 4. La Secretaria realiza modificaciones de datos. 5. La Secretaria solicita actualizar ficha clnica. 6. El sistema actualiza Ficha clnica. 7. El sistema muestra un mensaje Ficha Clnica grabada satisfactoriamente el caso de uso finaliza

3.2. Flujos Alternativos

Ninguno.

4. Requerimientos Especiales Ninguno.

5. Pre condiciones

Paciente Registrado Un Paciente debe existir en el sistema.

6. Post condiciones La modificacin queda registrada en el sistema.

7. Puntos de Extensin Este caso de uso incluye el Caso de Uso Buscar Paciente.

SCCOA Especificacin de Caso de Uso: Registrar cita

Versin 1.1

Historial de Revisiones

|Fecha tor |19/04/05 Uso de | Asencios | Pajuelo |04/06/05 Final | | | |

|Versin

|Descripcin

|Au

|1.0 |Yanir Arvalo |

|Descripcin de la Especificacin de Caso de | |Registrar Cita. |Julissa

|Laura

|1.1

|Revisin |SCCOA |

Especificacin de Caso de Uso: Registrar cita

1. Nombre: Registrar cita

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir la Secretaria para registrar una cita

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando la Secretaria solicita al Sistema Registrar cita.

1. Flujo Bsico

1. El Sistema muestra el Formulario de Registrar cita 2. El Sistema muestra el Formulario de Registro de Citas. 3. La secretaria solicita buscar el paciente. 4. El Sistema muestra datos (nombre y apellido del paciente) 5. La Secretaria solicita Asignar Horario de Cita. 6. El Sistema muestra en pantalla fecha y hora de la cita. 7. La Secretaria solicita Registrar Cita. 8. El sistema muestra mensaje Cita grabada Satisfactoriamente y el caso de uso finaliza.

3.2. Flujos Alternativos

Ninguno.

4. Requerimientos Especiales Ninguno.

5. Pre condiciones

Paciente Registrado Un Paciente debe existir en el sistema.

6. Post condiciones La cita queda registrada en el sistema.

7. Puntos de Extensin El Caso de Uso incluye Asignar Horario de Cita. El Caso uso extiende Registrar Paciente. El Caso de Uso incluye Buscar Paciente.

SCCOA Especificacin de Caso de Uso: Asignar Horario de cita

Versin 1.1

Historial de Revisiones

|Fecha tor |19/04/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de Caso de

Uso de | Cita. | Pajuelo |04/06/05 Final

|Yanir Arvalo |

| |Asignar Horario de

|Julissa Asencios | | |1.1 |Revisin |SCCOA |

| |Laura

Especificacin de Caso de Uso: Asignar Horario de cita

1. Nombre: Asignar Horario de cita

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir la Secretaria para Asignar Horario de cita. Este caso de uso se realiza cuando la secretaria registra una cita, est incluido en Registrar Cita.

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando la Secretaria solicita al Sistema Asignar Horario de cita

2. Flujo Bsico

1. El Sistema muestra el Formulario de Asignar Horario de cita 2. La Secretaria selecciona ao, mes y semana en la cual ser asignada la cita.

3. El sistema muestra los horarios disponibles del doctor. 4. La Secretaria elige Da y hora de la cita. 5. La Secretaria solicita al aceptar la operacin 6. El sistema acepta la operacin y el caso de uso finaliza.

3.2. Flujos Alternativos

Ninguno. 4. Requerimientos Especiales Ninguno.

5. Pre condiciones Ninguno.

6. Post condiciones Ninguno.

7. Puntos de Extensin

Ninguno.

SCCOA Especificacin de Caso de Uso: Seguimiento del Paciente

Versin 1.1

Historial de Revisiones

|Fecha tor |19/04/05 Uso de | Paciente. | Pajuelo |04/06/05 Final | | |

|Versin

|Descripcin

|Au

|1.0 |Yanir Arvalo |

|Descripcin de la Especificacin de Caso de | |Seguimiento del |Julissa Asencios | | |Laura

|1.1

|Revisin |SCCOA |

Especificacin de Caso de Uso: Seguimiento del Paciente

1. Nombre: Seguimiento del Paciente

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir el Administrador para poder revisar las descripciones de las citas que ingresa la secretaria y as poder llevar un seguimiento adecuado del paciente. Esta descripcin la encontramos dentro de la Ficha Clnica.

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando el Administrador solicita al Sistema revisar Seguimiento del Paciente.

3. Flujo Bsico

1. El Sistema muestra el Formulario Seguimiento del paciente. 2. Al administrador busca al paciente 3. El sistema muestra datos del paciente, del familiar y la descripcin de las citas realizadas y el caso de uso finaliza.

3.2. Flujos Alternativos

Ninguno.

4. Requerimientos Especiales Ninguno.

5. Pre condiciones Ninguno.

6. Post condiciones Ninguno.

7. Puntos de Extensin Este caso de uso incluye el caso de uso Buscar Paciente.

SCCOA Especificacin de Caso de Uso: Reporte De Pacientes Atendidos

Versin 1.1

Historial de Revisiones

|Fecha tor |19/04/05 Uso de | Atendidos. | Pajuelo |04/06/05 Final | | |

|Versin

|Descripcin

|Au

|1.0 |Yanir Arvalo |

|Descripcin de la Especificacin de Caso de | |Reporte de Pacientes

|Julissa Asencios |

| |Laura

|1.1

|Revisin |SCCOA |

Especificacin de Caso de Uso: Reporte de Pacientes Atendidos

1. Nombre: Reporte de Pacientes Atendidos

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir el Administrador para obtener un listado de los pacientes atendidos en la clnica.

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando el Administrador solicita al Sistema el

Reporte de Pacientes Atendidos

4. Flujo Bsico

1. El Sistema muestra el Formulario Reporte de pacientes atendidos. 2. El Administrador selecciona ao y mes. 3. El Administrador selecciona tipo de ordenacin (por cdigo, por apellido o por fecha) en la cual ser presentado el listado. 4. El Administrador solicita Consultar Pacientes. 5. El sistema muestra reporte de pacientes atendidos en las fechas solicitadas y el caso de uso finaliza.

3.2. Flujos Alternativos

3.2.1. Doctor Seleccionado. Antes de consultar pacientes (punto 4), si el administrador elige opcin mostrar doctor, al consultar pacientes en el listado saldr el doctor que atendi la cita.

4. Requerimientos Especiales Ninguno.

5. Pre condiciones Ninguno.

6. Post condiciones Ninguno.

7. Puntos de Extensin

Ninguno

SCCOA Especificacin de Caso de Uso: Consultar Cita

Versin 1.1

Historial de Revisiones

|Fecha |Versin | |02/06/05 Uso | Asencios | Pajuelo |05/06/05 final | |1.1 |Revisin |SCCOA | | | | |Laura |Yanir Arvalo | |1.0 |Descripcin de la Especificacin de Caso de | |Consultar Cita |Julissa |Descripcin |Autor

Especificacin de Caso de Uso: Consultar Cita

1. Nombre: Consultar Cita

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir la secretaria

para consultar las citas que han sido reservadas por los pacientes.

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando la secretaria solicita Consultar cita.

3.1 Flujo Bsico 6. El Sistema muestra el Formulario Consultar cita. 7. La secretaria selecciona ao, mes y da. 8. La Secretaria selecciona forma de ordenacin (por cdigo o por fecha) en la cual sern mostradas las citas de los pacientes. 9. La Secretaria solicita Consultar cita 10. El sistema muestra lista de citas de los pacientes que sern atendidos en la fecha solicitada y el caso de uso finaliza.

3.2 Flujos Alternativos

3.2.1. Imprimir Consulta de Citas En el punto 5, si se requiere obtener una copia impresa de la consulta realizada: 1. La secretaria solicita imprimir consulta 2. El sistema emite impresin de la consulta y el caso de uso finaliza

4.

Requerimientos Especiales Tener una impresora conectada al terminal de la Secretaria. Contar con hojas de Reporte de Citas.

5.

Pre condiciones Cita Registrada La cita debe estar registrada en el sistema.

6.

Post condiciones

7.

Puntos de Extensin Ninguno.

SCCOA Especificacin de Caso de Uso: Determinar Horario de Atencin por Medico

Versin 1.1

Historial de Revisiones

|Fecha tor |02/06/05 Uso de | Mdico. | Pajuelo | Polo | | | | | |

|Versin

|Descripcin

|Au

|1.0 |Yanir Arvalo |

|Descripcin de la Especificacin de Caso de | |Determinar Horario de Atencin por | |Laura

|Julissa Asencios | |

|Carla

|Ivette

Morales |05/06/05 final

| |1.1 |Revisin |SCCOA |

Especificacin de Caso de Uso: Determinar Horario de Atencin por Mdico

1.

Nombre: Determinar Horario de Atencin por Mdico

2.

Breve Descripcin Este caso de uso describe los procedimientos que debe seguir el

Administrador para determinar los horarios de atencin que sern asignados a los doctores.

3.

Flujos de Escenario

Evento Disparador El caso de uso comienza cuando el Administrador solicita registrar Horario de atencin por mdico.

1. Flujo Bsico 1. El Sistema muestra el Formulario Determinar Horario de Atencin por mdico. 2. El Administrador selecciona el nombre de doctor 3. El Administrador selecciona los horarios de atencin disponibles durante la semana y en los tres turnos (maana, tarde, noche), para el doctor seleccionado. 4. El Administrador solicita grabar para registrar el horario de atencin por mdico seleccionado. 5. El sistema graba la operacin. 6. El sistema muestra un mensaje Horario registrado satisfactoriamente y el

Caso de Uso finaliza.

3.2. Flujos Alternativos

3. Requerimientos especiales Ninguno. 5. Pre condiciones Doctor Registrado. El Doctor debe estar registrado en el sistema.

5. Post condiciones El Horario de Atencin del mdico queda registrado en el sistema. 6. Puntos de Extensin Ninguno.

SCCOA Especificacin de Caso de Uso: Eliminar cita

Versin 1.1

Historial de Revisiones

|Fecha tor |19/04/05 Uso | |Yanir Arvalo | |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de Caso de | |Actualizar cita |Julissa

Asencios | Pajuelo |05/06/05 final

| | | |1.1 |Revisin |SCCOA | | |Laura

Especificacin de Caso de Uso: Eliminar cita

1. Nombre: Eliminar Cita

2.

Breve Descripcin Este caso de uso describe los procedimientos que debe seguir la Secretaria

para eliminar (cancelar) una o varias citas que ha sido previamente solicitado por el paciente.

3. Flujo de Escenario

Evento Disparador El caso de uso comienza cuando la Secretaria solicita al Sistema Eliminar cita.

1. Flujo Bsico 1. El Sistema muestra el Formulario de Eliminar cita. 2. La secretaria selecciona ao, mes y da. 3. La secretaria selecciona el tipo de ordenacin requerida. 4. La secretaria solicita mostrar 5. El sistema muestra en pantalla las citas que coincidan con la fecha ingresada. 6. La Secretaria selecciona de la lista, la cita que desea eliminar. 7. La Secretaria selecciona eliminar.

8. El sistema muestra mensaje Cita eliminada Satisfactoriamente y el caso de uso finaliza.

3.2. Flujos Alternativos

3.2.1 Fecha no ingresada adecuadamente Si la secretaria no selecciona alguno de los campos sea: Ao, Da o Mes no se podr mostrar las Citas. Se muestra mensaje Debe Ingresar Fecha Correctamente y contina en el paso 2.

4. Requerimientos Especiales Ninguno.

5. Pre condiciones Cita registrada La cita debe estar registrada en el sistema.

6. Post condiciones Cita Registrada La cita queda eliminada en el sistema.

7. Puntos de Extensin Ninguno.

SCCOA Especificacin de Caso de Uso: Verificar Horario de Cita

Versin 1.1

Historial de Revisiones

|Fecha tor |19/05/05 Uso | Cita | Pajuelo |05/06/05 final | | |Yanir Arvalo | |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de Caso de | |Verificar Horario de

|Julissa Asencios |

| |Laura

|1.1

|Revisin |SCCOA |

Especificacin de Caso de Uso: Verificar Horario de Cita

1. Nombre: Verificar Horario de Cita

2. Breve Descripcin Este caso de uso describe los procedimientos que debe seguir el Paciente para verificar su horario de cita en el sistema. El paciente podr efectuar esta consulta va Web desde el lugar donde se encuentre.

3. Flujo de Escenario

Evento Disparador El caso de uso comienza cuando el Paciente solicita al sistema Verificar el

horario de su cita.

3.1. Flujo Bsico 1. El Sistema muestra ventana para verificar horario de cita. 2. El sistema muestra nombres y apellidos del paciente y del mdico asignado, fecha y hora de la cita y el Caso de Uso finaliza.

3.2. Flujos Alternativos Ninguno.

4. Requerimientos especiales

5. Pre condiciones Cita Registrada La cita del paciente debe estar registrada en el sistema.

6. Post condiciones Ninguno

7. Puntos de Extensin Ninguno.

SCCOA Especificacin de Caso de Uso: Buscar Paciente

Versin 1.1

Historial de Revisiones

|Fecha tor |19/04/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de Caso de | |Paciente |Julissa

Uso Buscar |Yanir Arvalo | Asencios | Pajuelo |05/06/05 Final | |1.1 | | | |

|Laura

|Revisin |SCCOA |

Especificacin de Caso de Uso: Buscar Paciente

1. Nombre: Buscar Paciente

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir la Secretaria para Buscar un Paciente (este caso de uso est incluido dentro de varios casos de uso. Ver modelo de casos de uso)

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando la Secretaria solicita al Sistema Buscar Paciente.

3.1 Flujo Bsico 1. El Sistema muestra el Formulario de Bsqueda de Pacientes. 2. La Secretaria ingresa dato del paciente a buscar (Apellido y/o Nombre) 3. La Secretaria solicita bsqueda 4. El sistema muestra listado de pacientes 5. La secretaria selecciona el paciente buscado y el caso de uso finaliza.

3.2. Flujos Alternativos

3.2.1. Paciente no encontrado Luego del paso 3, el sistema no encuentra datos que coincidan con el ingresado, entonces el sistema muestra mensaje Paciente No Encontrado y el Caso de Uso finaliza.

4. Requerimientos Especiales Ninguno

5. Pre condiciones Ninguno.

6. Post condiciones Ninguno.

7. Puntos de Extensin Ninguno.

SCCOA

Especificacin de Caso de Uso: Ingresar descripcin de cita

Versin 1.1

Historial de Revisiones

|Fecha |Versin | |19/04/05 Uso de | Cita. | Pajuelo |04/06/05 Final | |1.1 |Revisin |SCCOA | |1.0 |Yanir Arvalo | |Descripcin de la Especificacin de Caso de | |Ingresar Descripcin de | |Laura |Descripcin |Autor

|Julissa Asencios | |

Especificacin de Caso de Uso Anlisis: Ingresar Descripcin de Cita

1. Nombre: Ingresar Descripcin de Cita

2. Breve Descripcin

Este caso de uso describe los procedimientos que debe seguir la Secretaria para Registrar la descripcin del tratamiento brindado en la cita del paciente.

3. Flujos de Escenario

Evento Disparador El caso de uso comienza cuando la Secretaria solicita al Sistema Ingresar Descripcin de Cita.

3.1 Flujo Bsico 1. El Sistema muestra el Formulario de Ingreso de Descripcin de cita. 2. La Secretaria ingresa el nmero de ficha clnica del paciente. 3. La Secretaria selecciona aceptar 4. El sistema muestra datos personales y del familiar del paciente 5. La secretaria ingresa descripcin de la atencin brindado en la cita. 6. La secretaria solicita ingresar descripcin y el caso de uso finaliza

3.2. Flujos Alternativos

3.2.1. Seguimiento de descripcin ingresada Luego del paso 4, puede hacer una consulta de las descripciones ingresadas para ese paciente 1. La secretaria solicita Ver descripcin 2. El sistema muestra la (s) descripcin (es) ingresadas para ese paciente

4. Requerimientos Especiales Ninguno

5. Pre condiciones Paciente Registrado El paciente debe estar registrado y tener una cita registrada

6. Post condiciones Ficha clnica actualizada La ficha clnica del paciente ser actualizada con la descripcin de la cita

7. Puntos de Extensin Ninguno.

Anexo 13: Especificaciones de Realizaciones de Caso de Uso Anlisis

SCCOA Especificacin de Realizacin de Caso de Uso Anlisis: Actualizar datos de Paciente Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Actualizar datos del |

Realizacin de |SCCOA | paciente | |

Especificacin de Realizacin de Caso de Uso Anlisis: Actualizar Datos del Paciente

1. Introduccin 1.1 Propsito

El presente documento presenta como se llevarn a cabo los procedimientos para que la Secretaria realice la Actualizacin de los datos de los pacientes 1.2 Alcance Estas especificaciones servirn de base para la elaboracin de las especificaciones de realizacin de casos de uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4

Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Anlisis Actualizar Datos del Paciente: Flujo Bsico

SCCOA

Especificacin de Realizacin de Caso de Uso Anlisis: Asignar Horario de Cita Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Asignar Horario de

Realizacin de |SCCOA | |

Cita

Especificacin de Realizacin de Caso de Uso Anlisis: Asignar Horario de Cita

1. Introduccin 1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos para que la Secretaria realice la Asignacin de un horario de cita. 1.2 Alcance

Estas especificaciones servirn de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Anlisis Asignar Horario de Cita: Flujo Bsico

SCCOA Especificacin de Realizacin de Caso de Uso Anlisis: Consultar Cita Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Consultar

Realizacin de |SCCOA | Cita | |

Especificacin de Realizacin de Caso de Uso Anlisis: Consultar Cita

1. Introduccin 1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos para que la Secretaria realice la consulta de citas 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Anlisis Consultar Cita: Flujo Bsico

Consultar Cita: Flujo Alternativo: Imprimir Consulta

SCCOA

Especificacin de Realizacin de Caso de Uso Anlisis: Eliminar Cita Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Eliminar

Realizacin de |SCCOA | Cita | |

Especificacin de Realizacin de Caso de Uso Anlisis: Eliminar Cita

1. Introduccin 1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos para que la Secretaria realice la eliminacin de una cita de la base de datos de citas 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias

Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos Anlisis:

Eliminar Cita: Flujo Bsico [pic]

SCCOA Especificacin de Realizacin de Caso de Uso Anlisis: Ingresar Descripcin de Cita Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Ingresar Descripcin de |

Realizacin de |SCCOA | Cita | |

Especificacin de Realizacin de Caso de Uso Anlisis: Ingresar Descripcin de Cita

1. Introduccin 1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos

para que la Secretaria ingrese al sistema la descripcin y/o indicaciones derivadas de la cita llevada a cabo 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Anlisis Ingresar Descripcin de Cita-Flujo Bsico [pic]

Flujo Alternativo: Ver Descripciones de Cita

SCCOA Especificacin de Realizacin de Caso de Uso Anlisis: Registrar de Cita Versin 1.0

Historial de Revisiones

|Fecha

|Versin

|Descripcin

|Au

tor |11/06/05 |1.0 de |SCCOA | Cita

|Descripcin de la Especificacin de la Realizacin | | | |Caso de Uso: Registrar |

Especificacin de Realizacin de Caso de Uso Anlisis: Registrar Cita

1. Introduccin 1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos para que la Secretaria realice el Registro de Citas de los pacientes. 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Anlisis Registrar Cita-Flujo Bsico

SCCOA Especificacin de Realizacin de Caso de Uso Anlisis: Registrar Paciente Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Registrar

Realizacin de |SCCOA | Paciente | |

Especificacin de Realizacin de Caso de Uso Anlisis: Registrar Paciente

1. Introduccin 1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos para que la Secretaria realice el Registro Pacientes. 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

Registrar Paciente Flujo Alternativo: Enviar e_mail

Registrar Paciente Flujo Alternativo: Datos obligatorios no ingresados

SCCOA Especificacin de Realizacin de Caso de Uso Anlisis: Verificar Horario de Cita Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Verificar Horario de |

Realizacin de |SCCOA | Cita | |

Especificacin de Realizacin de Caso de Uso Anlisis : Verificar Horario de Cita

1. Introduccin 1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos para que el paciente pueda realizar consultas sobre el horario de su cita. 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Anlisis : Verificar Horario de Cita - Flujo Bsico

SCCOA Especificacin de Realizacin de Caso de Uso Anlisis: Buscar Paciente Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Buscar

Realizacin de |SCCOA | Paciente | |

Especificacin de Realizacin de Caso de Uso Anlisis: Buscar Paciente

1. Introduccin 1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos para que la secretaria realice la bsqueda de clientes en la base de datos. 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas

Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Anlisis: Buscar Paciente - Flujo Bsico

Buscar Paciente Flujo Alternativo: Paciente No Encontrado

SCCOA Especificacin de Realizacin de Caso de Uso Anlisis: Determinar Horario de Atencin por Mdico Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Determinar Horario de Atencin por |

Realizacin de |SCCOA | Mdico | |

Especificacin de Realizacin de Caso de Uso Anlisis: Determinar Horario de Atencin por Mdico

1. Introduccin

1.1 Propsito El presente documento presenta como se llevarn a cabo los procedimientos para que el administrador ingrese al sistema cuales sern los horarios de atencin por cada mdico. 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

2.

Flujo de eventos - Anlisis: Determinar Horario de Atencin por Mdico - Flujo Bsico

[pic]

SCCOA Especificacin de Realizacin de Caso de Uso: Seguimiento del Paciente Versin 1.0

Historial de Revisiones

|Fecha tor |11/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso: Seguimiento del

Realizacin de |SCCOA | |

Paciente

Especificacin de Realizacin de Caso de Uso Anlisis: Seguimiento del Paciente

1. Introduccin 1.1 Propsito

El presente documento presenta como se llevarn a cabo los procedimientos para que el administrador realice la consulta de las indicaciones registrada en la cita, para cada paciente. 1.2 Alcance Esta especificacin servir de base para la elaboracin de la Especificacin de la Realizacin de Caso de Uso de Diseo 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4 Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Anlisis: Seguimiento del Paciente - Flujo Bsico

Anexo 14: Prototipos de Interfaz Grfica de Usuario

SECRETARIA

[pic]

[pic]

[pic]

[pic]

[pic]

[pic]

[pic] [pic]

ADMINISTRADOR

[pic]

[pic]

[pic]

[pic]

[pic] [pic]

PACIENTE

[pic]

[pic]

Anexo 15: Mapas de Navegacin

Sistema Control de Citas Oftalmolgica Asmat Mapa de Navegacin

Versin 1.1

Historial de Versiones

|Fecha | |22/04/05 Yanir | Julissa | Ivette | Melita | Janett |15/06/05 Yanir | Julissa | | | | | | | | | | | |

|Versin

|Descripcin

|Autor

|1.0

|Versin inicial.

|Arevalo Salvador,

| | |

|Asencios Cerna,

|Morales Henderson,

|Polo Gonzales, Carla

|Pajuelo Grandez, Laura

|1.1

|Versin final

|Arevalo Salvador,

| | |

|Asencios Cerna,

|Morales Henderson,

Ivette | | | Janett | | | | | |

|Polo Gonzales, Carla Melita |

|Pajuelo Grandez, Laura

Introduccin

1. Propsito

Este documento tiene el propsito de mostrarnos la navegabilidad del usuario a travs de las distintas interfaces segn funcionalidad.

2. Alcance Este documento abarca todas las navegaciones de los usuarios a travs del Site.

3. Definiciones Ver Glosario

4. Referencias Visin 1.1

5. Descripcin El Mapa de Navegacin presenta una representacin grfica de la manera como el usuario debe navegar a travs de las distintas ventanas disponibles en el

Sistema SCCOA.

6. Mapa de Navegacin

1. Registrar Paciente

Breve Descripcin En este caso de uso la Secretaria ingresa un Nuevo Paciente a la base de datos de la Oftalmolgica Asmat. Mediante la interfaz que se diagrama a continuacin.

Modelo de Elementos

[pic] Mapa de Navegacin

[pic]

Storyboard

[pic]

Mapa Arquitectnico

2. Reporte Pacientes Atendidos

Breve Descripcin

En este caso de uso la Administrador de la Oftalmolgica Asmat hace una consulta de los pacientes atendidos en la oftalmolgica en una determinada fecha a su libre eleccin.

Modelo de Elementos

[pic] Mapa de Navegacin

[pic]

Storyboard

[pic]

Mapa Arquitectnico

[pic] 3. Verificar Horario de Cita Por Paciente

Breve Descripcin

En este caso de uso el paciente de la oftalmolgica Asmat podr verificar el horario de su cita sin necesidad de llamar a la Oftalmolgica.

Modelo de Elementos

[pic]

Mapa de Navegacin

[pic]

Storyboard

[pic]

Mapa Arquitectnico

[pic]

7. Ingresar Descripcin de Cita

Breve Descripcin

En este caso de uso la Secretaria de la Oftalmolgica Asmat ingresa una pequea descripcin hecha por el doctor y que nos servir para hacerle un seguimiento rpido al paciente sin necesidad de consultar toda la Ficha Clnica.

Modelo de Elementos [pic]

Mapa de Navegacin

[pic]

Storyboard

[pic]

Mapa Arquitectnico

[pic]

1. Ingresar Descripcin de Cita

Breve Descripcin

En este caso de uso la Secretaria de la Oftalmolgica Asmat ingresa una pequea descripcin hecha por el doctor y que nos servir para hacerle un seguimiento rpido al paciente sin necesidad de consultar toda la Ficha Clnica.

Modelo de Elementos

[pic]

Mapa de Navegacin

[pic]

Storyboard

[pic]

Mapa Arquitectnico

[pic]

Anexo 16 : Especificacin de la Realizacin de caso de uso de diseo

SCCOA Especificacin de Realizacin de Caso de Uso de Diseo: Actualizar datos de Paciente Versin 1.0

Historial de Revisiones

|Fecha tor |13/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso de Diseo: Actualizar datos del |

Realizacin de |SCCOA | paciente | |

Especificacin de Realizacin de Caso de Uso de Diseo: Actualizar Datos del Paciente

1. 1.1

Introduccin Propsito El presente documento presenta los diagramas de secuencia de como se

disearon los procedimientos para que la Secretaria realice la Actualizacin de los datos de los pacientes 1.2 Alcance Estas especificaciones servirn de base para realizar la implementacin (cdigo) en la que el sistema deber cumplir con los requisitos indicados. 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4

Referencias Modelo realizado utilizando herramienta Rational Rose.

2.

Flujo de eventos - Diseo

Diagrama de Secuencia: Actualizar Datos del Paciente: Flujo Bsico

Diagrama de Colaboracin: Actualizar Datos del Paciente: Flujo Bsico

SCCOA Especificacin de Realizacin de Caso de Uso de Diseo: Consultar Cita Versin 1.0

Historial de Revisiones

|Fecha tor |13/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la

Realizacin de |SCCOA | Cita | |

| |Caso de Uso de Diseo: Consultar |

Especificacin de Realizacin de Caso de Uso de Diseo: Consultar Cita

1. 1.1

Introduccin Propsito El presente documento presenta los diagramas de secuencia de como se

disearon los procedimientos para que la Secretaria realice la consulta de citas 1.2 Alcance Estas especificaciones servirn de base para realizar la implementacin (cdigo) en la que el sistema deber cumplir con los requisitos indicados. 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4

Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos Diseo Consultar Cita: Flujo Bsico

Diagrama de colaboracin: Consultar cita

SCCOA Especificacin de Realizacin de Caso de Uso de Diseo: Eliminar Cita Versin 1.0

Historial de Revisiones

|Fecha tor |13/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso de Diseo: Eliminar |

Realizacin de |SCCOA | Cita | |

Especificacin de Realizacin de Caso de Uso de Diseo: Eliminar Cita

1. 1.1

Introduccin Propsito El presente documento presenta los diagramas de secuencia de como se

disearon los procedimientos para que la Secretaria realice la eliminacin de una cita de la base de datos de citas 1.2 Alcance Estas especificaciones servirn de base para realizar la implementacin (cdigo) en la que el sistema deber cumplir con los requisitos indicados. 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4

Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Diseo Eliminar Cita: Flujo Bsico

Diagrama de colaboracin: Eliminar Cita

SCCOA Especificacin de Realizacin de Caso de Uso de Diseo: Ingresar Descripcin de Cita Versin 1.0

Historial de Revisiones

|Fecha tor |13/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso de Diseo: Ingresar Descripcin de

Realizacin de |SCCOA | Cita | | |

Especificacin de Realizacin de Caso de Uso de Diseo: Ingresar Descripcin de Cita

1. 1.1

Introduccin Propsito El presente documento presenta los diagramas de secuencia de como se

disearon los procedimientos para que la Secretaria ingrese al sistema la descripcin y/o indicaciones derivadas de la cita llevada a cabo 1.2 Alcance Estas especificaciones servirn de base para realizar la implementacin (cdigo) en la que el sistema deber cumplir con los requisitos indicados. 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4

Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos Diseo Ingresar Descripcin de Cita-Flujo Bsico

SCCOA Especificacin de Realizacin de Caso de Uso de Diseo: Registrar de Cita Versin 1.0

Historial de Revisiones

|Fecha tor |13/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin | |Caso de Uso de Diseo: Registrar |

de la Realizacin de |SCCOA | Cita | |

Especificacin de Realizacin de Caso de Uso de Diseo: Registrar Cita

1. 1.1

Introduccin Propsito El presente documento presenta los diagramas de secuencia de como se

disearon los procedimientos para que la Secretaria realice el Registro de Citas de los pacientes. 1.2 Alcance

Estas especificaciones servirn de base para realizar la implementacin (cdigo) en la que el sistema deber cumplir con los requisitos indicados. 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4

Referencias Modelo realizado utilizando herramienta Rational Rose.

2.

Flujo de eventos Diseo Registrar Cita-Flujo Bsico

Diagrama de colaboracin: Registrar Cita

SCCOA Especificacin de Realizacin de Caso de Uso de Diseo: Registrar Paciente Versin 1.0

Historial de Revisiones

|Fecha tor |13/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso de Diseo: Registrar |

Realizacin de |SCCOA | Paciente | |

Especificacin de Realizacin de Caso de Uso de Diseo: Registrar Paciente

1.

Introduccin

1.1

Propsito El presente documento presenta los diagramas de secuencia de como se

disearon los procedimientos para que la Secretaria realice el Registro Pacientes. 1.2 Alcance Estas especificaciones servirn de base para realizar la implementacin (cdigo) en la que el sistema deber cumplir con los requisitos indicados. 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4

Referencias Modelo realizado utilizando herramienta Rational Rose.

2. Flujo de eventos - Diseo : Registrar Paciente-Flujo Bsico [pic]

Anexo 17 : Modelo de Persistencia

[pic]

Anexo 18 : Realizaciones de casos de uso en la Web

SCCOA Especificacin de Realizacin de Caso de Uso de Diseo: Verificar Horario de Cita Versin 1.0

Historial de Revisiones

|Fecha tor |13/06/05 |

|Versin

|Descripcin

|Au

|1.0

|Descripcin de la Especificacin de la | |Caso de Uso de Diseo: Verificar Horario de |

Realizacin de |SCCOA | Cita | |

Especificacin de Realizacin de Caso de Uso de Diseo: Verificar Horario de Cita

1. 1.1

Introduccin Propsito El presente documento presenta los diagramas de secuencia de como se

disearon los procedimientos para que el paciente puede realizar consultas sobre el horario de su cita. 1.2 Alcance Estas especificaciones servirn de base para realizar la implementacin (cdigo) en la que el sistema deber cumplir con los requisitos indicados. 1.3 Definiciones, acrnimos y abreviaturas Ver Glosario

1.4

Referencias Modelo realizado utilizando herramienta Rational Rose.

2. [pic]

Flujo de eventos - Diseo Verificar Horario de Cita - Flujo Bsico

Anexo 19 : Script

SCRIPT

CREATE TABLE TelefonoxPaciente ( IdPaciente CHAR ( 10 ) NOT NULL, IdTipoTelefono VARCHAR ( 10 ) NOT NULL, nroTel DECIMAL ( 38 ) NOT NULL, CONSTRAINT PK_TelefonoxPaciente PRIMARY KEY NONCLUSTERED (IdPaciente, IdTipoTelefono) ) GO CREATE TABLE Doctor ( IdCabeceraFichaClinica INT, IdTipoDocumento CHAR ( 1 ) NOT NULL, nombre VARCHAR ( 25 ) NOT NULL, apePat VARCHAR ( 30 ) NOT NULL, apeMat VARCHAR ( 30 ) NOT NULL, nroColgiaturaDoc SMALLINT NOT NULL, IdCita CHAR ( 4 ) NOT NULL, CONSTRAINT PK_Doctor PRIMARY KEY NONCLUSTERED (nroColgiaturaDoc) ) GO CREATE TABLE TipoDocumento ( IdTipoDocumento CHAR ( 1 ) NOT NULL, descripcion VARCHAR ( 35 ) NOT NULL, CONSTRAINT PK_TipoDocumento PRIMARY KEY NONCLUSTERED (IdTipoDocumento) )

GO CREATE TABLE Paciente ( IdPaciente CHAR ( 10 ) NOT NULL, IdCabeceraFichaClinica INT NOT NULL, IdTipoDocumento CHAR ( 1 ) NOT NULL, apePat VARCHAR ( 20 ) NOT NULL, apeMat VARCHAR ( 20 ) NOT NULL, nombre VARCHAR ( 20 ) NOT NULL, fecNac DATETIME NOT NULL, estadoCivil VARCHAR ( 10 ) NOT NULL, direccion VARCHAR ( 50 ) NOT NULL, mail VARCHAR ( 30 ) NOT NULL, pwd VARCHAR ( 10 ) NOT NULL, usuario VARCHAR ( 10 ) NOT NULL, CONSTRAINT PK_Paciente PRIMARY KEY NONCLUSTERED (IdPaciente) ) GO CREATE TABLE Secretaria ( IdSecretaria INT NOT NULL, nombre VARCHAR ( 20 ) NOT NULL, apePat VARCHAR ( 30 ) NOT NULL, apeMat VARCHAR ( 30 ) NOT NULL, dniSecretaria INT NOT NULL, IdCita CHAR ( 4 ) NOT NULL, CONSTRAINT PK_Secretaria PRIMARY KEY NONCLUSTERED (dniSecretaria) ) GO CREATE TABLE TipoCita (

IdTipoCita CHAR ( 4 ) NOT NULL, descripcion VARCHAR ( 25 ) NOT NULL, CONSTRAINT PK_TipoCita PRIMARY KEY NONCLUSTERED (IdTipoCita) ) GO CREATE TABLE DetalleFichaClinica ( IdDetalleFichaClinica INT NOT NULL, IdCabeceraFichaClinica INT NOT NULL, indicaciones VARCHAR ( 35 ) NOT NULL, diagnostico VARCHAR ( 35 ) NOT NULL, CONSTRAINT PK_DetalleFichaClinica PRIMARY KEY NONCLUSTERED (IdDetalleFichaClinica) ) GO CREATE TABLE FamiliarPaciente ( IdFamiliarPaciente CHAR ( 10 ) NOT NULL, IdPaciente CHAR ( 10 ) NOT NULL, IdTipoDocumento CHAR ( 1 ) NOT NULL, apePat VARCHAR ( 20 ) NOT NULL, apeMat VARCHAR ( 25 ) NOT NULL, nombre VARCHAR ( 20 ) NOT NULL, parentesco VARCHAR ( 10 ) NOT NULL, direccion VARCHAR ( 30 ) NOT NULL, telefono BIGINT NOT NULL, mail VARCHAR ( 20 ) NOT NULL, CONSTRAINT PK_FamiliarPaciente PRIMARY KEY NONCLUSTERED (IdFamiliarPaciente) )

GO

CREATE TABLE Horario ( Id_Horario CHAR ( 4 ) NOT NULL, DIA DATETIME NOT NULL, hora DATETIME NOT NULL, fecha DATETIME NOT NULL, CONSTRAINT PK_Horario PRIMARY KEY NONCLUSTERED (Id_Horario) ) GO CREATE TABLE Cita ( IdPaciente CHAR ( 10 ) NOT NULL, IdTipoCita CHAR ( 4 ) NOT NULL, Id_Horario CHAR ( 4 ) NOT NULL, descripcion VARCHAR ( 25 ) NOT NULL, IdCita CHAR ( 4 ) NOT NULL, CONSTRAINT PK_Cita100 PRIMARY KEY NONCLUSTERED (IdCita) ) GO CREATE TABLE HorarioXDoctor ( Id_Horario CHAR ( 4 ) NOT NULL, Turno VARCHAR ( 15 ) NOT NULL, nroColgiaturaDoc SMALLINT NOT NULL, CONSTRAINT PK_HorarioXDoctor96 PRIMARY KEY NONCLUSTERED (nroColgiaturaDoc, Id_Horario) ) GO

CREATE TABLE CabeceraFichaClinica ( IdCabeceraFichaClinica INT NOT NULL, fechaRegistro DATETIME NOT NULL, CONSTRAINT PK_CabeceraFichaClinica PRIMARY KEY NONCLUSTERED (IdCabeceraFichaClinica) ) GO CREATE TABLE TipoTelefono ( IdTipoTelefono VARCHAR ( 10 ) NOT NULL, IdFamiliarPaciente CHAR ( 10 ), tipTelefono SMALLINT NOT NULL, CONSTRAINT PK_TipoTelefono PRIMARY KEY NONCLUSTERED (IdTipoTelefono) ) GO ALTER TABLE TelefonoxPaciente ADD CONSTRAINT FK_Pac_TelPac FOREIGN KEY (IdPaciente) REFERENCES Paciente (IdPaciente) GO ALTER TABLE TelefonoxPaciente ADD CONSTRAINT FK_TipTel_TelPac FOREIGN KEY (IdTipoTelefono) REFERENCES TipoTelefono (IdTipoTelefono) GO ALTER TABLE Doctor ADD CONSTRAINT FK_CabFicCli_Doc FOREIGN KEY (IdCabeceraFichaClinica) REFERENCES CabeceraFichaClinica (IdCabeceraFichaClinica) GO ALTER TABLE Doctor ADD CONSTRAINT FK_TipDoc_Doc FOREIGN KEY (IdTipoDocumento) REFERENCES TipoDocumento (IdTipoDocumento) GO

ALTER TABLE Doctor ADD CONSTRAINT FK_Doctor135 FOREIGN KEY (IdCita) REFERENCES Cita (IdCita) GO ALTER TABLE Paciente ADD CONSTRAINT FK_TipDoc_Pac FOREIGN KEY (IdTipoDocumento) REFERENCES TipoDocumento (IdTipoDocumento) GO ALTER TABLE Paciente ADD CONSTRAINT FK_CabFicClin_Pac FOREIGN KEY (IdCabeceraFichaClinica) REFERENCES CabeceraFichaClinica (IdCabeceraFichaClinica) GO ALTER TABLE Secretaria ADD CONSTRAINT FK_Secretaria134 FOREIGN KEY (IdCita) REFERENCES Cita (IdCita) GO ALTER TABLE DetalleFichaClinica ADD CONSTRAINT FK_CabFicClin_DetFicClin FOREIGN KEY (IdCabeceraFichaClinica) REFERENCES CabeceraFichaClinica (IdCabeceraFichaClinica) GO ALTER TABLE FamiliarPaciente ADD CONSTRAINT FK_TipDoc_FamPac FOREIGN KEY (IdTipoDocumento) REFERENCES TipoDocumento (IdTipoDocumento) GO ALTER TABLE FamiliarPaciente ADD CONSTRAINT FK_Pac_FamPac FOREIGN KEY (IdPaciente) REFERENCES Paciente (IdPaciente) GO ALTER TABLE Cita ADD CONSTRAINT FK_Pac_Cita FOREIGN KEY (IdPaciente) REFERENCES Paciente (IdPaciente) GO

ALTER TABLE Cita ADD CONSTRAINT FK_TipCita_Cita FOREIGN KEY (IdTipoCita) REFERENCES TipoCita (IdTipoCita) GO ALTER TABLE Cita ADD CONSTRAINT FK_Hor_Cita FOREIGN KEY (Id_Horario) REFERENCES Horario (Id_Horario) GO ALTER TABLE HorarioXDoctor ADD CONSTRAINT FK_Hor_HorDoc FOREIGN KEY (Id_Horario) REFERENCES Horario (Id_Horario) GO ALTER TABLE HorarioXDoctor ADD CONSTRAINT FK_Doc_HorDoc FOREIGN KEY (nroColgiaturaDoc) REFERENCES Doctor (nroColgiaturaDoc) GO ALTER TABLE TipoTelefono ADD CONSTRAINT FK_FamPac_TipTel FOREIGN KEY (IdFamiliarPaciente) REFERENCES FamiliarPaciente (IdFamiliarPaciente) GO

Anexo 20 : Caso de Pruebas

CASOS DE PRUEBA Caso de Uso Registrar Paciente 1. Evento Disparador El caso de uso comienza cuando la Secretaria solicita al Sistema Registrar un Paciente. 2. Flujo Bsico 1. El Sistema muestra el Formulario de Registro de Paciente.====UC1 2. La Secretaria ingresa datos personales del paciente (nombres, apellidos, nmero de documento, domicilio, distrito, provincia, telfono, fecha de nacimiento, estado civil, e-mail)====UC2

3. La Secretaria ingresa datos del familiar del paciente (nombre, apellido, parentesco, nmero de documento, domicilio y telfono)=======UC3 4. La Secretaria solicita generar Ficha Clnica==========UC4 5. El sistema graba Ficha clnica=======UC5 6. El sistema muestra un mensaje Ficha Clnica grabada satisfactoriamente ====UC6 7. La secretaria solicita imprimir una constancia de registro de usuario y password.==UC7 8. El sistema emite constancia de registro de usuario y password y el caso de uso finaliza.===UC8 3. Flujos Alternativos Datos obligatorios no ingresados En el punto 4, si entre los datos personales del paciente a excepcin del e-mail no han sido ingresados, el sistema mostrara el mensaje llenar todos los campos obligatorios solicitados. Y el caso de uso contina en el punto 2.

Enviar Mail Despus del punto 6: Si se ha ingresado e_mail del paciente en el punto 2 La secretaria elige Opcin enviar e-mail El sistema enva correo electrnico de confirmacin de usuario y password. El sistema muestra un mensaje "mail enviado satisfactoriamente".

Complejidad Ciclomatica a) N regiones + 1 = 3 b) N nodos predicados + 1 = 3 c) A N + 2 = 14 - 13+ 2 = 3 Trayectorias

 Trayectoria 1 (Registro normal de pacientes, sin envo de correo electrnico): o inicio, 1, 2, 3, 4, 5, 6, 7, 8, fin Trayectoria 2: (Registro normal de pacientes, con envo de correo electrnico) o inicio, 1, 2, 3, 4, 5, 6, 6.1 ,6.1.1, 7, 8, fin Trayectoria 3: (Registro de pacientes Datos obligatorios no ingresados, con envo de correo electrnico o inicio, 1, 2, 3, 4, 4.1, 2, 3, 4, 5, 6, 6.1, 6.1.1, 7, 8, fin Trayectoria 4: (Registro de pacientes Datos obligatorios no ingresados, sin envo de correo electrnico o inicio, 1, 2, 3, 4, 4.1, 2, 3, 4, 5, 6, 7, 8, fin

SCCOA Caso de Uso: Registrar Paciente Caso de Prueba: Registro normal de pacientes, sin envo de correo electrnico

Caso de Prueba: Trayectoria 1: Registro normal de pacientes, sin envo de correo electrnico

1. Propsito.Probar que la secretaria podr realizar el registro de pacientes en la base de datos, con la informacin solicitada. 2. Pre-requisitos El paciente no haya sido registrado todava. 3. Datos de Prueba Datos personales: Nombre, Apellido paterno, Apellido materno, Fecha de nacimiento, Edad, Tipo de documento, Nro. De documento, Estado civil, Nmero telefnico, Direccin, Distrito , Provincia. Datos familiares: Nombre, apellidos, documento de identidad, telfono,

direccin. 4. Pasos 1. Ingresar a la ventana de registro de paciente 2. Ingresar los datos solicitados del paciente, excepto correo electrnico 3. Ingresar los datos solicitados del familiar 4. Hacer clic en Generar Ficha Clnica 5. Ver: la ventana de confirmacin Ficha clnica generada satisfactoriamente 6. Hacer clic en Imprimir comprobante 7. Recibir: impresin del comprobante de registro

SCCOA Caso de Uso: Registrar Paciente Caso de Prueba: Registro normal de pacientes, con envo de correo electrnico

Caso de Prueba: Trayectoria 2: Registro normal de pacientes, con envo de correo electrnico

1. Propsito.Probar que la secretaria podr realizar el registro de pacientes en la base de datos, con la informacin solicitada y enviarle a dicho paciente un correo de confirmacin de su cita.

2. Pre-requisitos El paciente no haya sido registrado todava.

3. Datos de Prueba Datos personales: Nombre, Apellido paterno, Apellido materno, Fecha de

nacimiento, Edad, Tipo de documento, Nro. De documento, Estado civil, Nmero telefnico, Direccin, Distrito , Provincia. Datos familiares: Nombre, apellidos, documento de identidad, telfono, direccin. 4. Pasos 1. Ingresar a la ventana de registro de paciente 2. Ingresar los datos solicitados del paciente, incluyendo el correo electrnico (debe ser un correo al cual tengamos acceso para poder comprobar). 3. Ingresar los datos solicitados del familiar 4. Hacer clic en Generar Ficha Clnica 5. Ver la ventana de confirmacin Ficha clnica generada satisfactoriamente 6. Hacer clic en Enviar e_mail 7. Ver la ventana de confirmacin E_mail enviado satisfactoriamente 8. Ingresar a la cuenta de correo electrnico para comprobar que hemos recibido el mensaje de confirmacin de la clnica. 9. Hacer clic en Imprimir comprobante 10. Recibir: impresin del comprobante de registro

SCCOA Caso de Uso: Registrar Paciente Caso de Prueba: Registro de pacientes Datos obligatorios no ingresados, con envo de correo electrnico

Caso de Prueba: Trayectoria 3: Registro de pacientes Datos obligatorios no ingresados, con envo de correo electrnico

1. Propsito.-

Probar que la secretaria deber ingresar obligatoriamente los datos indicados, para poder realizar el registro de pacientes en la base de datos y enviarle a dicho paciente un correo de confirmacin de su cita.

2. Pre-requisitos El paciente no haya sido registrado todava. 3. Datos de Prueba Datos personales: Nombre, Apellido paterno, Apellido materno, Fecha de nacimiento, Edad, Tipo de documento, Nro. De documento, Estado civil, Nmero telefnico, Direccin, Distrito , Provincia. Datos familiares: Nombre, apellidos, documento de identidad, telfono, direccin. 4. Pasos 1. Ingresar a la ventana de registro de paciente 2. Ingresar los datos del paciente, incluyendo el correo electrnico (debe ser un correo al cual tengamos acceso para poder comprobar). En este paso se deber dejar en blanco por lo menos un campo de los datos considerados obligatorios 3. Ingresar los datos solicitados del familiar 4. Hacer clic en Generar Ficha Clnica 5. Ver la ventana con el mensaje: Ingresar todos los campo obligatorios 6. Ver nuevamente la ventana de registro de pacientes 7. Ingresar los datos solicitados del paciente, incluyendo datos obligatorios y el correo electrnico (debe ser un correo al cual tengamos acceso para poder comprobar). 8. Ingresar los datos solicitados del familiar 9. Hacer clic en Generar Ficha Clnica 10. Ver la ventana de confirmacin Ficha clnica generada satisfactoriamente 11. Hacer clic en Enviar e_mail

12. Ver la ventana de confirmacin E_mail enviado satisfactoriamente 13. Ingresar a la cuenta de correo electrnico para comprobar que hemos recibido el mensaje de confirmacin de la clnica. 14. Hacer clic en Imprimir comprobante 15. Recibir: impresin del comprobante de registro Notas Esta trayectoria deber ser probada con cada uno de los campos considerados como obligatorios, para garantizar su correcto flujo.

SCCOA Caso de Uso: Registrar Paciente Caso de Prueba: Registro de pacientes Datos obligatorios no ingresados, sin envo de correo electrnico

Caso de Prueba: Trayectoria 4: Registro de pacientes Datos obligatorios no ingresados, sin envo de correo electrnico

1. Propsito.Probar que la secretaria deber ingresar obligatoriamente los datos indicados, para poder realizar el registro de pacientes en la base de datos. 2. Pre-requisitos El paciente no haya sido registrado todava.

3. Datos de Prueba Datos personales: Nombre, Apellido paterno, Apellido materno, Fecha de nacimiento, Edad, Tipo de documento,

Nro. De documento, Estado civil, Nmero telefnico, Direccin, Distrito , Provincia. Datos familiares: Nombre, apellidos, documento de identidad, telfono, direccin. Pasos 1. Ingresar a la ventana de registro de paciente 2. Ingresar los datos del paciente. En este paso se deber dejar en blanco por lo menos un campo de los datos considerados obligatorios 3. Ingresar los datos solicitados del familiar 4. Hacer clic en Generar Ficha Clnica 5. Ver la ventana con el mensaje: Ingresar todos los campos obligatorios 6. Ver nuevamente la ventana de registro de pacientes 7. Ingresar los datos solicitados del paciente, incluyendo datos obligatorios. 8. Ingresar los datos solicitados del familiar 9. Hacer clic en Generar Ficha Clnica 10. Ver la ventana de confirmacin Ficha clnica generada satisfactoriamente 11. Hacer clic en Imprimir comprobante 12. Recibir: impresin del comprobante de registro Notas Esta trayectoria deber ser probada con cada uno de los campos considerados como obligatorios, para garantizar su correcto flujo.

[pic][pic][pic] ----------------------- Listado Citas por paciente - Listado Citas por doctor - Informacin horarios libres - Inf. Horario de trabajo por usuario

Horario de Doctores

Usuario

Secretaria Paciente Doctor

BASE DE DATOS

SCCOA

- Almacenamiento - Consulta

- Citas por paciente - Citas por doctor - Horarios disponibles - Horario de trabajo por usuario

Julissa Asencios Analista Negocio

Laura Pajuelo Analista Negocio

Carla Polo Analista Negocio

Yanir Arvalo Analista Sistemas

Henry Miranda Analista Negocio

Ivette Morales Henderson Jefe de Proyecto

Flujo de eventos - Anlisis : Registrar Paciente-Flujo Bsico

MODELO DE PERSISTENCIA

Diagrama de colaboracin: Ingresar Descripcin de cita

Solicita generar ficha

MSG: llenar todos los campos obligatorios solicitados

Si se ingreso e_mail

MSG: Ficha Clnica grabada satisfactoriamente

Solicita Envo de e_mail de confirmacin

MSG: "mail enviado satisfactoriamente".

4.1

6.1

6.1.1

Asignar Horario de Cita: Flujo Bsico

[pic]