expediente médico electrónico

Proyecto:

“Electronic Medical File”

Código del proyecto:

<EMF-001-12>

Elaborado por:

Ariana Cerdas Quesada

Melvin Jiménez

Alejandra Flores

Marianyela Magallón Hernández

Jenny Sandoval

Profesor:

Marvin Solano Campos

Versión: 1.0

Nota de Propiedad

El uso de este documento es confidencial y es propiedad exclusiva de la empresa <

WORLD BUSINESS SOFTWARE COSTA RICA>, por tanto su uso está restringido

únicamente a la empresa que realizó la contratación.

HISTORIAL DE REVISIONES

Fecha Versión Descripción Autor

24/09/2012 1.0 Entrega de la

documentación del

programa.


Melvin Jímenez Araya


Alejandra Flores

Jenny Sándoval

15/10/2012 1.0 Modificación del

planeamiento del

programa e

implementaciones en el

software


Melvin Jímenez Araya


Alejandra Flores

Jenny Sándoval

30/10/2012 1.0 Elaboración del

Documento


Melvin Jiménez Araya


Alejandra Flores

Jenny Sandoval

06/11/2012 1.0 Entrega de Casos de

Uso




Alejandra Flores

Jenny Sandoval

Firmas de Aprobación:

Dueño del Proyecto Jefe de la Unidad Solicitante o persona designada como

encargado general del Proyecto.

Marianyela Magallón

Firma:

Fecha:15/10/2012

Administrador del

Proyecto

Encargado de Administrar el Proyecto por parte de TI.

Melvin Jímenez

Firma:

Fecha:15/10/2012

Tabla de contenido 1 Perfil del proyecto .......................................................... ¡Error! Marcador no definido.

1.1 Nombre del Proyecto: .................................................... ¡Error! Marcador no definido.

1.2 Nombre del Gerente del Proyecto: ................................ ¡Error! Marcador no definido.

1.3 Antecedentes: ................................................................ ¡Error! Marcador no definido.

1.4 Objetivos del Proyecto: ................................................. ¡Error! Marcador no definido.

1.5 Descripción Funcional del Producto: ............................ ¡Error! Marcador no definido.

1.6 Alcance del Proyecto: .................................................... ¡Error! Marcador no definido.

1.7 Supuestos: ...................................................................... ¡Error! Marcador no definido.

1.8 Restricciones: ................................................................ ¡Error! Marcador no definido.

2 Requerimientos del proyecto ......................................... ¡Error! Marcador no definido.

2.1 Descripción General ...................................................... ¡Error! Marcador no definido.

2.2 Especificación de requerimientos funcionales............... ¡Error! Marcador no definido.

2.2.1 Registro de Pacientes .......................................... ¡Error! Marcador no definido.

2.2.2 Registro de Médicos ............................................ ¡Error! Marcador no definido.

2.2.3 Almacenamiento del Historial Médico ................ ¡Error! Marcador no definido.

2.3 Especificación de requerimientos no funcionales.......... ¡Error! Marcador no definido.

2.3.1 Plataforma ............................................................ ¡Error! Marcador no definido.

2.3.2 Seguridad y antivirus ........................................... ¡Error! Marcador no definido.

2.3.3 Fiabilidad ............................................................. ¡Error! Marcador no definido.

2.3.4 Mantenibilidad ..................................................... ¡Error! Marcador no definido.

2.3.5 Hardware ............................................................. ¡Error! Marcador no definido.

2.3.6 Conexion a Internet ............................................. ¡Error! Marcador no definido.

2.3.7 Portabilidad .......................................................... ¡Error! Marcador no definido.

3 Casos de Uso ................................................................... ¡Error! Marcador no definido.

3.1 Caso de Uso # 1 “Control de acceso” ............................ ¡Error! Marcador no definido.

3.2 Caso de Uso # 2 “Registro de Pacientes” ...................... ¡Error! Marcador no definido.

3.3 Caso de Uso # 3 “Registro Médico” .............................. ¡Error! Marcador no definido.

3.4 Caso de Uso # 4 “Consultas al Expediente Médico” ..... ¡Error! Marcador no definido.

4 Especificación suplementaria ........................................ ¡Error! Marcador no definido.

5 Plan de Proyecto ............................................................. ¡Error! Marcador no definido.

6.1 Antecedentes.................................................................. ¡Error! Marcador no definido.

6.2 Objetivos del Proyecto .................................................. ¡Error! Marcador no definido.

6.3 Metodología de Trabajo ................................................ ¡Error! Marcador no definido.

6.4 Estrategia general .......................................................... ¡Error! Marcador no definido.

6.5 Mecanismo de seguimiento y control ............................ ¡Error! Marcador no definido.

6.6 Control de Cambios ....................................................... ¡Error! Marcador no definido.

6.7 Personal clave en el proyecto ........................................ ¡Error! Marcador no definido.

6.8 Entregables esperados del proyecto ............................... ¡Error! Marcador no definido.

6.9 Control de Calidad del proyecto .................................... ¡Error! Marcador no definido.

6.10 Cronograma de trabajo .................................................. ¡Error! Marcador no definido.

6.11 Riesgos claves del Proyecto .......................................... ¡Error! Marcador no definido.

6 Informe de Avance ......................................................... ¡Error! Marcador no definido.

7.1 Información general y estado del proyecto .................... ¡Error! Marcador no definido.

7.2 Avance del proyecto en el período reportado ................ ¡Error! Marcador no definido.

7.3 Logros Obtenidos Durante el Período Reportado .......... ¡Error! Marcador no definido.

7.4 Problemas Actuales Presentados en el Período Reportado¡Error! Marcador no definido.

7.5 Actividades en Proceso al Cierre del Período Reportado¡Error! Marcador no definido.

7.6 Objetivos para el Próximo Período a Reportar .............. ¡Error! Marcador no definido.

7.7 Anexo Cronograma actualizado del Proyecto .............. ¡Error! Marcador no definido.

7 Prototipos ........................................................................ ¡Error! Marcador no definido.

8.1 Logo del producto .......................................................... ¡Error! Marcador no definido.

8.2 Pantallas ......................................................................... ¡Error! Marcador no definido.

8.3 Uso de la paleta de colores y tipo de letras .................... ¡Error! Marcador no definido.

8.4 Tipos de Botones ........................................................... ¡Error! Marcador no definido.

8.5 Formularios de las pantallas .......................................... ¡Error! Marcador no definido.

8.6 Tipos de Objeto ............................................................. ¡Error! Marcador no definido.

8.7 Tamaños de las pantallas ............................................... ¡Error! Marcador no definido.

8.8 Posición de los objetos .................................................. ¡Error! Marcador no definido.

8 Plan de Pruebas .............................................................. ¡Error! Marcador no definido.

PERFIL DEL PROYECTO ...................................................................................................................... 9

Requerimientos del proyecto .................................................................................................................. 12

1.1 Nombre del requerimiento: Registro y modificación de Pacientes. ................... 12

1.2 Nombre del requerimiento: Registro y modificación de Médicos ..................... 14 1.3. Nombre del requerimiento: Almacenamiento de historial médico. ....................... 15

2. Especificación de requerimientos no funcionales .............................................. 16 3. Estimación de tiempo para el desarrollo de los requerimientos ......................... 17

4. Descripción de las Reglas del Negocio .............................................................. 17 5. Observaciones .................................................................................................... 17

Casos de uso ........................................................................................................................................... 18

2. Casos de Uso ...................................................................................................... 18

2.1. Caso de Uso # 1: Control de acceso ................................................................... 18 2.2 Caso de Uso # 2: Registro de Pacientes ............................................................. 19

2.3 Caso de Uso # 3: Registro Médico ..................................................................... 20 2.4 Caso de Uso # 4: Consultas al Expediente Médico ............................................ 21

1. Diagrama Casos de Uso ..................................................................................... 22 Especificaciones Suplementarias .................................................................................. 23

Plan de Proyecto ..................................................................................................................................... 25

1 Antecedentes................................................................................................................................... 25

2 Objetivos del Proyecto.................................................................................................................... 25

3 Metodología de Trabajo .................................................................................................................. 26

3.1 Estrategia general ............................................................................................... 26 3.2 Mecanismo de seguimiento y control ................................................................. 27 3.3 Control de Cambios ............................................................................................ 27

4 Personal clave en el proyecto ......................................................................................................... 28

5 Entregables esperados del proyecto ................................................................................................ 30

6 Control de Calidad del proyecto ..................................................................................................... 31

7 Cronograma de trabajo ................................................................................................................... 31

Riesgos claves del Proyecto ................................................................................................................... 32

Informe seminal de Actividades ............................................................................................................. 33

8 Información general y estado del proyecto ..................................................................................... 33

Avance del proyecto en el período reportado ......................................................................................... 34

Logros Obtenidos Durante el Período Reportado ................................................................................... 34

9 Problemas Actuales Presentados en el Período Reportado ............................................................. 36

10 Actividades en Proceso al Cierre del Período Reportado .......................................................... 36

11 Objetivos para el Próximo Período a Reportar .......................................................................... 36

8. Anexo Cronograma actualizado del Proyecto ................................................................................... 38

Prototipo ................................................................................................................................................. 39

1 Logo del producto y su acrónimo ................................................................................................... 39

Acrónimo del producto: EMF-001-12 .................................................................................................... 39

2 Pantallas .......................................................................................................................................... 39

2.1 Uso de la paleta de colores y tipo de letras ........................................................ 40 2.2 Tipos de Botones ................................................................................................ 42 2.3 Formularios de las pantallas ............................................................................... 44

2.3.1 Tipos de Objeto ................................................................................................................ 56

2.3.2 Tamaños de las pantallas .................................................................................................. 56

2.3.3 Posición de los objetos ...................................................................................................... 56

3 Reportes .......................................................................................................................................... 56

Plan de Pruebas....................................................................................................................................... 58

Introducción ............................................................................................................................................ 59

11.1 Tipos de pruebas ................................................................................................. 60 11.2 Niveles de pruebas ............................................................................................. 60 11.3 El Plan de Pruebas .............................................................................................. 61

12 descripción del proceso de prueba ............................................................................................. 62

12.1 Estrategia de prueba ........................................................................................... 62 12.1.1 Formalidad del proceso ................................................................................................ 62

12.1.2 Agilidad en la comunicación ........................................................................................ 62

12.1.3 Fondo sobre la forma .................................................................................................... 63

12.1.4 Ambiente controlado .................................................................................................... 63

12.1.5 Integración del equipo de prueba ................................................................................. 63

12.1.6 Actitud constructiva para la prueba .............................................................................. 63

12.2 Niveles de prueba ............................................................................................... 64 12.2.1 Pruebas de regresión ..................................................................................................... 64

12.2.2 Pruebas de módulos ...................................................................................................... 66

12.3 Seguimiento del proceso de pruebas .................................................................. 68 13 Calendarización del proceso de prueba ..................................................................................... 70

14 Organización y roles para el proceso de prueba ........................................................................ 71

14.1 Coordinador del equipo de prueba ..................................................................... 71 14.2 Especialista técnico ............................................................................................ 71 14.3 Especialista en soporte técnico ........................................................................... 72

14.4 Especialista del área funcional ........................................................................... 72 14.5 Analista de negocio ............................................................................................ 72

14.6 Desarrollador del producto ................................................................................. 73

14.7 Asesor metodológico .......................................................................................... 73 15 Requerimientos y consideraciones para el proceso de prueba ................................................... 74

15.1 Base de datos de prueba ..................................................................................... 74 15.2 Instalaciones físicas para pruebas ...................................................................... 74 15.3 Componentes tecnológicos ................................................................................. 74 15.4 Asignación del personal ..................................................................................... 75

15.5 Instrucción previa ............................................................................................... 75 15.6 Paralelismo ......................................................................................................... 75

Solicitud de cambio ................................................................................................................................ 77

3 Glosario .............................................................................................................. 80 Anexos .......................................................................................................................... 83

Anexo 1– Formato para Casos de Prueba ..................................................................... 90 Anexo 2 – Formato para Reporte de Hallazgos ............................................................ 90 Anexo 3– Detalle de Pruebas a Realizar ....................................................................... 91 Anexo 4 – Asignación del Equipo de trabajo ............................................................... 92

10 Anexos ............................................................................. ¡Error! Marcador no definido.

PERFIL DEL PROYECTO

1. Nombre del Proyecto:

2. Nombre del Gerente del Proyecto:

Alejandra Flores


Jenny Sandoval



3. Antecedentes:

La clínica Santa Teresita actualmente necesita de un sistemas digital, ya que

por los grandes volúmenes de información de los pacientes que se manejan

sería más eficiente un sistema que le lleve el control de medicamentos, citas

médicas, síntomas, padecimientos, registro de médicos, especialidades

entre otros; ya que es de suma importancia el orden para eficiencia además

de garantizar el seguimiento del estado de cada paciente, y así crecer en

calidad de servicio tanto como en la atención de las emergencias y el ahorro

de tiempo en llenar expedientes . Un sistema digital disminuiría en parte las

tareas del secretario u enfermera que llene los datos de cada paciente ya

que utilizando expedientes o folder contribuiría a que se traspapele alguna

hoja del mismo asegurando el orden como se menciono anteriormente.

4. Objetivos del Proyecto:

“Electronic Medical File EMF”

Objetivo General:

1. Implementar un sistema que se utilice como un expediente médico

electrónico en un plazo de 6 meses a un costo de $20000.

Objetivos Específicos:

1. Agilizar los procesos de inscripciones de pacientes y médicos dentro

del centro hospitalario.

2. Mantener el orden en la Clínica Santa Terecita.

3. Proporcionar una mejor calidad del servicio a todos los pacientes y

médicos de la clínica.

4. Evitar la perdida de información médica.

5. Colaborar con el buen funcionamiento del sistema implementado en la

clínica.

5. Descripción Funcional del Producto:

El software deberá llenar las expectativas del usuario previamente

solicitadas.

El producto final debe ser eficiente y amigable con el usuario.

Sus funciones específicamente serán:

Inicialmente mostrará una página principal, en la que el usuario puede

elegir lo que desea realizar, esto se encuentra separado por pestañas,

debidamente identificadas con la nueva página a la que se re-

direccionan.

En cada una de estas pestañas el usuario puede insertar, modificar ó

borrar datos de la base de datos que contiene la información.

El software también permite hacer distintas consultas a la base de

datos, ya sea almacenada con anterioridad ó recién ingresada al

sistema.

Entre sus consultas, el usuario tendrá la posibilidad de elegir qué tipo

de consulta desea realizar, ya sea por medico, paciente ó historial

médico.

El sistema almacenará toda esta información en el sistema, de manera que

la información sea accesada de manera rápida y eficiente

6. Alcance del Proyecto:

Entregables del proyecto:

Primera etapa: Documentación del software

Segunda Etapa: “Electronic Medical File EMF”

Tercera Etapa: Manual del programador, manual de usuario escrito y

en video tutorial

Métricas:

Bitácoras para cumplir con la fecha establecida de entrega

uso de cronogramas.

Capacitaciones para el personal

Exclusiones del proyecto: interfaces con los demás departamentos de la

clínica.

7. SUPUESTOS:

La herramienta de desarrollo: Software Electronic Medical File EMF

Lenguaje de desarrollo: Visual Studio .Net 2008

La licencia de base de datos: SQL SERVER 2008 R2.

El hardware a utilizar: CPU’s, Acceso a la red.

8. RESTRICCIONES:

De formato como las cédulas, teléfonos, monedas, estado\ civil, idioma tanto

del sistema como de los productos, el logo del software, etc.

Desarrollado por:

Alejandra Flores


Jenny Sandoval



Fecha: 17- 09 - 2012

Requerimientos del proyecto

Descripción General

Este documento permite realizar una descripción detallada de los requerimientos que

forman parte del proyecto. Los requerimientos se definen en forma clara y precisa

para un adecuado entendimiento por parte del equipo de trabajo técnico asignado al

proyecto.

Tabla 1. Lista de requerimientos funcionales

N° Nombre Requerimiento Tipo de Req.

Prioridad

1 Registro y modificación de Pacientes. Nuevo ALTA

2 Registro y modificación de Médicos. Nuevo MEDIA

3 Almacenamiento de historial médico. Nuevo ALTA

1. Especificación de requerimientos funcionales

1.1 Nombre del requerimiento: Registro y modificación de Pacientes.

Actores: Médicos, Enfermeras, Departamento de Registro

Detalle del requerimiento Este requerimiento se encarga de realizar el ingreso de pacientes al sistema. Deberá ingresarse en la información personal, el nombre completo, numero de cedula, la fecha de nacimiento, sexo, edad, estado civil y cantidad de hijos. Esto con la finalidad de llevar un control adecuado de cada uno de los pacientes ingresados, y así poder guardar su información personal en el sistema.

Relación con otros sistemas Se relaciona con el sistema de historial médico del paciente y con el registro de médicos.

Restricciones

De formato como las cédulas, teléfonos, estado\civil, idioma del sistema.

Formatos de pantalla y reportes La pantalla para ingresar, modificar y ver datos se desplegará de la siguiente forma.

Reglas del negocio

No Aplica

1.2 Nombre del requerimiento: Registro y modificación de Médicos

Actores Médicos, Departamento de Registro

Detalle del requerimiento Este requerimiento se encarga de realizar el ingreso de médicos al sistema. Deberá ingresarse en la información del médico, el nombre completo, numero de médico, teléfono y su especialidad. Esto con la finalidad de llevar un control adecuado de cada uno de los médicos interinos o residentes que laboran en la clínica.

Relación con otros sistemas Se relaciona con el sistema de historial médico del paciente y con el registro y modificación de pacientes.

Restricciones

De formato como el numero de médico, teléfonos, estado\civil, idioma del sistema.

Formatos de pantalla y reportes La pantalla para ingresar y modificar datos se desplegará de la siguiente forma.

1.3. Nombre del requerimiento: Almacenamiento de historial médico.

Actores Médicos, Departamento de registro.

Detalle del requerimiento Este requerimiento se encargara de almacenar toda la información médica del paciente por medio de un botón llamado Buscar se podrá desplegar la información personal, información médica general, especialidades médicas y análisis de laboratorio según el paciente indicado en la búsqueda.

Relación con otros sistemas Se relaciona con el registro y modificación de pacientes.

Restricciones Solo se puede escoger los pacientes que ya fueron cargados al sistema desde antes.

Formatos de pantalla y reportes La pantalla para ingresar y modificar datos se desplegará de la siguiente forma.

Reglas del negocio

No aplica.

2. Especificación de requerimientos no funcionales Los requerimientos no funcionales se refieren a todas las disposiciones del entorno requerido para que el sistema opere satisfactoriamente.

N° Nombre Requerimiento Tipo de Req.

Prioridad

1 Plataforma (preferiblemente Windows 7 sp1): Las plataformas contaran con un 95% de componentes dependientes del servidor en uso. El sistema se realizara en Visual Studio 2008 como lenguaje determinado para la realización del sistema y la base de datos en SQL Server 2008 R2.

Nuevo ALTA

2 Seguridad y antivirus: en relación con la seguridad el sistema será protegido por contraseñas cada una proporcionada de acuerdo al rol que corresponda. En caso de que se quiera ingresar a un rol que no le corresponda será totalmente restringido y validado por el sistema. Y muy importante una buena protección con antivirus

Nuevo MEDIA

3 Fiabilidad Nuevo ALTA

4 Mantenimiento: Se realizará una vez al mes para revisar el buen funcionamiento y así evitar que se de perdida de algún dato relacionado con la base hospitalaria o programación siempre y cuando esté dentro de los parámetros establecidos en el contrato.

Ajuste BAJA

5 Rendimiento del sistema operativo Ajuste MEDIA

6 Hardware ( 25 PC’S Y 1 SERVIDOR ): El sistema debe emplearse en un aproximado de 25 ordenadores, distribuidos de la siguiente manera 12 en consultorios, 6 en admisión, 5 en el departamento de enfermería y 2 ordenadores disponibles para realizar las distintas consultas dependiendo de su perfil. Además de un servidor donde estará la base de datos.

Nuevo ALTA

7 Conexión a internet directa y/o inalámbrica.

Ajuste MEDIA

8 Portabilidad del software Ajuste BAJA

3. Estimación de tiempo para el desarrollo de los requerimientos

La duración para el desarrollo del proyecto serán 6 meses

aproximadamente con un total de 960 horas.

4. Descripción de las Reglas del Negocio

Es necesario tener presente que el no poseer licencias originales en los ordenadores, queda bajo responsabilidad del cliente y no de la empresa.

El diseño y desarrollo del software será realizado bajo las descripciones que el cliente indique, en caso de reclamo por faltante de algún detalle que el cliente no indico antes de la firma del contrato no serán tomados en cuenta; a menos de que se rectifique de nuevo el proyecto.

La manera de pago será 50% de adelanto como seña de trato y al finalizar el proyecto se cancelará el restante de la suma establecida.

El mantenimiento del software será establecido para un periodo de 1 año; después de la fecha será cobrado.

5. Observaciones Leer las reglas del negocio para evitar inconvenientes en su trámite.

Casos de uso

Descripción General Este documento permite realizar una descripción detallada de los casos de

uso, diagrama de casos de uso, especificaciones suplementarias y glosario

de términos, que forman parte del proyecto. Los requerimientos se definen

en forma clara y precisa para un adecuado entendimiento por parte del

equipo de trabajo técnico asignado al proyecto.

2. Casos de Uso

2.1. Caso de Uso # 1: Control de acceso

Caso de Uso Control de acceso ID 01

Actor Primario: Administrador Secundario: Personal de soporte

Propósito Mantener la seguridad del uso del sistema por medio del control de acceso

Resumen Verificar que los datos del usuario son correctos, para que puedan entrar al sistema y realizar todas las operaciones que deseen dentro del mismo, además agregar nuevos pacientes y médicos, como también la eliminación y modificación de la información de los pacientes

Tipo Medio y esencial

Referencias Cruzada

No aplica

Curso Normal de los Eventos

EVENTO SISTEMA

1.El usuario inicia el programa 2. Digita la contraseña y usuario correspondiente.

3. El sistema valida el login y password correcto. 4. El sistema le concederá al usuario realizar solo las operaciones permitidas según el perfil.

Flujos Alternos

A1: El usuario no existe. La secuencia A1 inicia en el punto 3

1. El sistema muestra el error y rechaza su ingreso El escenario vuelve al punto 2. A2: Contraseña incorrecta. La secuencia A2 inicia en el punto 3

1. El sistema muestra el error. 2. Inicia un contador. 3. Si el número de intentos es mayor de 4 el usuario es bloqueado.

El escenario vuelve al punto 1. A3: Usuario bloqueado. La secuencia A3 inicia en el punto 3

1. El sistema indica que el usuario ha sido bloqueado. El escenario vuelve al punto 1.

2.2 Caso de Uso # 2: Registro de Pacientes

Caso de Uso Registro de Pacientes ID 02

Actor Primario : Recepcionista o Secretario/a Secundario : Médico (Permitido solo para el área de pacientes)

Propósito Recepcionista: Insertar al paciente en el sistema y editarlos. También la inscripción de los médicos al sistema con derecho a editar datos. E ingresar los resultados de los análisis médicos. Consulta de la lista de pacientes insertados en el sistema. Médico: Ingresar síntomas y valoraciones correspondientes del paciente.

Resumen Recepcionista: Deberá ingresar los datos personales del paciente al momento de ingresar a la clínica. Inscribir a los nuevos pacientes y la posibilidad de editar a los existentes. Ingresar resultados del análisis médico realizado por el laboratorio de la clínica. Médico: Le corresponde ingresar las valoraciones que le realice al doliente en Información General y Especialidades Médicas.

Tipo Primario y esencial

Referencias Cruzada

Se relaciona con el sistema de historial médico del paciente y con el registro de médicos.


EVENTO SISTEMA

1. El paciente acude al centro hospitalario y el recepcionista le pide los datos. 2.El usuario ingresa a la pestaña administración elige una de las dos opciones: Pacientes o Médicos 4. Digita los datos del paciente o médico. 6.Editar datos 8.Consultar la lista 10. Ingreso del análisis médico, Información general y especialidades médicas para pacientes.

3. El sistema presentará la pantalla correspondiente 5. En caso de agregar paciente o medico: valida que la información digitada sea correcta y verifica si ya el id del paciente o médico existe. 7. Al seleccionar el id y nombre para editar los datos, el sistema presenta los datos que serán permitidos para editar. 9. El sistema le proporciona la visibilidad de las listas de pacientes y médicos. 11. El sistema le proporciona: los tipos de análisis, médicos y también tendrá que ingresar observaciones, tratamiento y diagnostico.

Flujos Alternos A1:Eliminar información del paciente La acción no es permitida para ningún usuario del sistema por lo que regresa al punto 3. A2:Faltante de datos en el sistema Se dará un error volviendo a al punto 5.

2.3 Caso de Uso # 3: Registro Médico

Caso de Uso Consultas al Expediente Médico ID 03

Actor Primario : Recepcionista o Secretario/a

Propósito Recepcionista: Inserta al médico en el sistema y también lo puede editar y eliminar. Consulta la lista de médicos insertados en el sistema, con su respetivo ID, nombre y su número de teléfono.

Resumen Recepcionista: Deberá ingresar los datos personales del médico al momento de ingresar a la clínica, así como su especialidad en el campo médico.


Referencias Cruzada

Se relaciona con el registro de médicos.


EVENTO SISTEMA

1. El Médico acude al centro hospitalario y el recepcionista le pide los datos. 2. El usuario ingresa a la pestaña administración elige la opción Médicos. 4. Digita los datos del médico. 6.Editar datos 8.Consultar la lista

3. El sistema presentará la pantalla correspondiente 5. En caso de agregar médico se valida que la información digitada sea correcta y verifica si ya el id del médico exista. 7. Al seleccionar el id y nombre para editar los datos, el sistema presenta los datos que serán permitidos para editar. 9. El sistema le proporciona la visibilidad de las listas de médicos.

Flujos Alternos

1.El médico acude al centro Hospitalario Resulta que no hay campos. 2. No sé puedan editar los campos. 3. No se puedan guardar los cambios.

4.El código asignado no sea el que aparece En la lista , así que no puede tener acceso Al centro hospitalario.

2.4 Caso de Uso # 4: Consultas al Expediente Médico

Caso de Uso Consultas al Expediente Médico ID 04

Actor Primario : Recepcionista o Secretario/a Secundario : Médicos

Propósito Consulta de los pacientes

Resumen Los médicos y recepcionistas tendrán acceso para la consulta del historial de padecimientos, últimas citas, datos personales de los pacientes entre otras.


Referencias Cruzada

Se relaciona con el registro de pacientes, análisis de laboratorio, Información médica general


EVENTO SISTEMA

1. El Médico busca el nombre del paciente 3.Consulta el expediente electrónico de su paciente Médicos.

2. El sistema presentará un buscador con todos los pacientes 4. El sistema le muestra datos personales, Información médica general, análisis de laboratorio, observaciones entre otras.

Flujos Alternos

A1: Se valida la existencia del paciente

1. Diagrama Casos de Uso

Especificaciones Suplementarias Las especificaciones suplementarias se refieren a todas las disposiciones del entorno requerido para que el sistema opere satisfactoriamente.

N° Especificaciones Suplementarias Tipo. Prioridad

1 Se hará un ajuste con los campos de teléfono, para

que a la hora de ingresar el usuario digite la

cantidad de ocho dígitos.

Ajuste Media

2 Se trabajará con las fechas del sistema, para que

de esta manera el formato sea más corto.

El nuevo formato será dd/mm/yyyy.

Ajuste Media

3 Se creará una nueva opción donde el usuario

tendrá que escoger por medio de un combo box el

estado civil del paciente, esto con el fin de

aligerar el proceso de ingreso.

Nuevo Media

4 Plataforma (preferiblemente Windows 7 sp1): Las plataformas contaran con un 95% de componentes dependientes del servidor en uso. El sistema se realizara en Visual Studio 2008 como lenguaje determinado para la realización del sistema y la base de datos en SQL Server 2008 R2.

Nuevo Alta

5 Seguridad y antivirus: en relación con la seguridad el sistema será protegido por contraseñas cada una proporcionada de acuerdo al rol que corresponda. En caso de que se quiera ingresar a un rol que no le corresponda será totalmente restringido y validado por el sistema. Y muy importante una buena protección con antivirus

Nuevo Media

6 Fiabilidad Nuevo Alta

7 Mantenimiento: Se realizará una vez al mes para revisar el buen funcionamiento y así evitar que se de perdida de algún dato relacionado con la base hospitalaria o programación siempre y cuando esté dentro de los parámetros establecidos en el contrato.

Ajuste Baja

N° Especificaciones Suplementarias Tipo. Prioridad

8 Rendimiento del sistema operativo Ajuste Media

9 Hardware ( 25 PC’S Y 1 SERVIDOR ): El sistema debe emplearse en un aproximado de 25 ordenadores, distribuidos de la siguiente manera 12 en consultorios, 6 en admisión, 5 en el departamento de enfermería y 2 ordenadores disponibles para realizar las distintas consultas dependiendo de su perfil. Además de un servidor donde estará la base de datos.

Nuevo Alta

10 Conexión a internet directa y/o inalámbrica. Ajuste Media

11 Portabilidad del software Ajuste Baja

Plan de Proyecto

1 Antecedentes

La clínica Santa Teresita actualmente necesita de un sistemas digital, ya que

por los grandes volúmenes de información de los pacientes que se manejan

sería más eficiente un sistema que le lleve el control de medicamentos, citas

médicas, síntomas, padecimientos, registro de médicos, especialidades

entre otros; ya que es de suma importancia el orden para eficiencia además

de garantizar el seguimiento del estado de cada paciente, y así crecer en

calidad de servicio tanto como en la atención de las emergencias y el ahorro

de tiempo en llenar expedientes . Un sistema digital disminuiría en parte las

tareas del secretario u enfermera que llene los datos de cada paciente ya

que utilizando expedientes o folder contribuiría a que se traspapele alguna

hoja del mismo asegurando el orden como se menciono anteriormente.

2 Objetivos del Proyecto Objetivo General:

6. Implementar un sistema que se utilice como un expediente médico

electrónico en un plazo de 6 meses a un costo de $10000.

Objetivos Específicos:

6. Agilizar los procesos de inscripciones de pacientes y médicos dentro

del centro hospitalario.

7. Mantener el orden en la Clínica Santa Terecita.

8. Proporcionar una mejor calidad del servicio a todos los pacientes y

médicos de la clínica.

9. Evitar la perdida de información médica.

Colaborar con el buen funcionamiento del sistema implementado en la

clínica.

3 Metodología de Trabajo

El proyecto seguirá la estructura según las aprobaciones pactadas en las reuniones de seguimiento y por medio de los documentos: administración del negocio, control de cambios, revisión de acuerdos, plan de pruebas, la administración de riegos para el producto, informes de avance y la aprobación de los entregables anteriores.

3.1 Estrategia general Describe las fases del proyecto. Deben estar alineadas al ciclo de vida del producto. Para cada una debe especificar el objetivo, quien la ejecuta y por último los entregables

Etapa Entregable Responsable Aprueba INICIO

Perfil del Proyecto Clínica Sta

Terecita Melvin Jiménez

Marianyela

Magallón

Documento de

requerimientos funcionales y no funcionales.

Clínica Sta

Terecita Melvin Jiménez

Marianyela

Magallón

Documento de casos de uso

Melvin Jiménez Marianyela

Magallón

Diagrama de casos de uso


Magallón

Matriz de manejo de riesgos.

Alejandra Flores Melvin Jiménez

Alejandra

Flores

Acta de Inicio


Magallón

Planificación del Proyecto

Plan de Proyecto

Jenny Sandoval.

Clínica Sta

Terecita

EJECUCION

Documento de

Requerimientos Ariana Cerdas.

Marianyela

Magallón Clínica Sta

Terecita Melvin

Jiménez

Diseño y análisis de

Requerimientos Alejandra

Flores

Marianyela

Magallón Melvin

Jiménez

3.2 Mecanismo de seguimiento y control

Se realizarán revisiones cada semana para llevar en orden el cumplimiento de las actividades estimadas y controla el tiempo de ejecución de las mismas. Cada jefe de departamento deberá elaborar un informe que se entregará cada jueves al Administrador del Proyecto. Se entregará un informe general de las actividades realizadas en la semana.

3.3 Control de Cambios

Se documentará todo cambio generado durante la ejecución del proyecto que difiera de lo que fue planificado, incluyendo el costo-beneficio y otros impactos del cambio, con el fin de que el Patrocinador tome la decisión de si se realiza el cambio solicitado por el Usuario. El patrocinador es el responsable de decidir si se realiza un cambio solicitado por el usuario.

4 Personal clave en el proyecto

Se presenta la lista del personal clave que participara en el Proyecto.

Funcionario Puesto Depto Nº Teléfono Email Responsabilidad

Marianyela Magallón

Dueño del proyecto

Cliente 2222-3445 [email protected]

Patrocinador del Producto

Aprobador de las etapas.

Coordinar y dar información acerca de su proyecto.

Melvin Jiménez

Administrador del proyecto

Administración de Proyectos.

3456-9898 [email protected]

Liderar el desarrollo del sistema

Dar seguimiento a cada etapa del desarrollo del sistema, realizar informes de cada avance y aprobar etapas.

Alejandra Flores

Analista de proyecto

Área de Proyectos

2245-0909 [email protected]

Analizar los requerimientos.

Analizar cada etapa de desarrollo por parte del programador y revisar los requerimientos.

Ariana cerdas Programador Área Desarrollo

de software. 3445-9898 AriC@hotmail.

com Desarrollar el producto de software.

Desarrollar los requerimientos y hacer pruebas al software desarrollado.

Jenny Sandoval Programador Área Desarrollo

de software. 8787-0909 jenny@hotmai

l.com Desarrollar el producto de software.

Desarrollar los requerimientos y hacer pruebas al software desarrollado.

5 Entregables esperados del proyecto

A continuación se presenta una matriz que muestra los entregables del proyecto, así como los responsables asignados para su ejecución.

Entregable Medio de Entrega

Plazo Entrega

Periodo

Revisión Perfil del proyecto definitivo

Impreso 3 días 4 días Documento de requerimientos funcionales y no funcionales. Digital 5 días 2 días Documento de casos de uso

Digital 2 días 3 días Diagrama de casos de uso

Impreso 1 día 1 día Matriz de manejo de riesgos.

Impreso 3 días 4 días Acta de Inicio

Impreso 1 día 1 día Plan de Proyecto

Impreso 3 días 5 días Documento de Requerimientos

Impreso 8 días 10 días Diseño y análisis de Requerimientos Digital 15 días 10 días Programación de los requerimientos. Impreso 60 días 4 días Pruebas técnicas de los requerimientos. Digital 2 días 2 días Prueba del usuario.

Impreso 1 día 1 día Elaboración de manuales

Correo electrónico

Y digital

15 días 12 días

Desarrollo de la capacitación. Correo electrónico

Y presencial

5 días 4 días

Informes de avance Impreso 4 días 2 días

Minutas Impreso 2 días 1 día

Acta de cierre Impreso 1 día 1 día

Solicitudes de cambio Correo electrónico

4 días 3 días

Instalación y entrega del producto. Impreso 3 días 3 días

31

Entregable Medio de Entrega

Plazo Entrega

Periodo

Revisión Acta de cierre del proyecto

Impreso 2 días 1 día

6 Control de Calidad del proyecto No aplica.

7 Cronograma de trabajo Hipervínculo hacía el Project1.mpp

Project1.mpp

32

Riesgos claves del Proyecto

04 Matriz Manejo Riesgos FINAL.xls

04%20Matriz%20Manejo%20Riesgos%20FINAL.xls

33

Informe seminal de Actividades

El presente informe semanal representa el estado actual del proyecto ELECTRONIC MEDICAL

FILE, los logros o hitos alcanzados y los problemas presentados durante la CONTEMPLA

ejecución en el período comprendido entre el 27/09/12 y el 10/12/12.

7.1.1.1 Preparado por:

Rol Nombre Firma Fecha

Administrador Melvin Jiménez 06/10/12

Programadora Ariana Cerdas 06/10/12

Programadora Jenny Sandoval 06/10/12

Analista Alejandra Flores 06/10/12

Diseñadora Marianyela Magallón 06/10/12

7.1.1.2 ESTE DOCUMENTO SE DISTRIBUYE A:

7.1.1.3 Nombre 7.1.1.4 Área 7.1.1.5 Puesto

7.1.1.6 7.1.1.7 7.1.1.8

7.1.1.9 7.1.1.10 7.1.1.11

7.1.1.12 7.1.1.13 7.1.1.14

7.1.1.15 7.1.1.16 7.1.1.17

8 Información general y estado del proyecto

Fecha de inicio: 27/09/12

Fecha base de finalización 10/12/12

Fecha estimada de finalización 10/12/12

Estado del proyecto Verde

34

Verde: No existen desviaciones en la ejecución de las actividades, ni problemas ni riesgos que impacten la finalización a tiempo del proyecto.

Amarillo: Se han dado desviaciones o presentado problemas o riesgos que pueden impactar la finalización. Se pueden tomar acciones para no impactar la fecha de finalización.

Rojo: Se presentaron desviaciones en el plan de trabajo, o se materializaron riesgos que impactan la fecha de finalización.

Avance del proyecto en el período reportado

En este estado actual del proyecto se ha logrado concluir por completo la etapa de inicio del proyecto y se tiene casi concluida la etapa de elaboración del proyecto. En la etapa de inicio se tiene concluido al 100% las siguientes actividades: el perfil del proyecto, documento de requerimientos funcionales y no funcionales, documento de casos de uso, especificaciones suplementarias y el glosario de términos. De la etapa de elaboración se tiene concluido el informe de avance, el perfil del proyecto y además se tiene terminado el documento de prototipos. Por lo que se tiene el proyecto en su etapa de finalización, terminando antes del tiempo que se tenía estimado.

Logros Obtenidos Durante el Período Reportado 3.1 Actividades y tareas concluidas en el período reportado:

ID Actividad/Tarea Fecha base Inicio

Fecha real

inicio

Fecha base

finalización

Fecha real finalización

Desfase días

hábiles

Respon-sable

Comentarios

1 Elaboración Perfil

Proyecto

10/10/12 15/10/12 29/10/12 30/10/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

Se concluyo en el

tiempo establecido

2 Elaboración

documento de

Requerimientos

funcionales y No

funcionales

12/10/12 12/10/12 16/10/12 20/10/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

3 Elaboración

documento Casos de

Uso

21/10/12 21/10/12 23/10/12 23/10/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

4 Elaboración

Especificaciones

Suplementarias

24/11/12 24/11/12 27/11/12 27/11/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

Se desarrollo en el

tiempo previsto

35

5 Elaboración Glosario

de Términos

26/11/12 26/11/12 31/11/12 31/11/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

6 Elaboración matriz

de Riesgos

29/11/12 30/11/12 03/12/12 03/12/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

Hubo un problema

por lo que no se

pudo inciar en la

fecha establecida

7 Elaboración Plan del

Proyecto

01/12/12 01/12/12 09/12/12 10/12/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

8 Elaboración Informe

de Avances

30/11/12 30/11/12 03/12/12 03/12/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

9 Elaboración

documento de

Prototipos

26/11/12 27/11/12 07/12/12 08/12/12 1 Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

3.2 Hitos finalizados en el período reportado:

Entregable Fecha estimada

aceptación

Fecha real aceptación

Comentarios

Elaboración Perfil Proyecto 29/10/12 01/11/12 Se aceptó correctamente

Elaboración documento de

Requerimientos funcionales y No

funcionales

01/11/12 01/11/12 Se aceptó correctamente

Elaboración documento Casos de

Uso


Elaboración Especificaciones

Suplementarias


Elaboración Glosario de Términos 22/11/12 22/11/12 Se aceptó correctamente

Elaboración matriz de Riesgos 22/11/12 22/11/12 Se aceptó correctamente

Elaboración Plan del Proyecto 25/11/12 25/11/12 Se aceptó correctamente

Elaboración Informe de Avances 27/11/12 27/11/12 Se aceptó correctamente

Elaboración documento de 30/11/12 30/11/12 Se aceptó correctamente

36

Prototipos

3.3 Problemas o riesgos resueltos en el período reportado:

ID Problema/Riesgo Fecha Resolución

Comentarios

1 Especificaciones de requerimientos incompletas 15/11/12 Riesgo controlado

9 Problemas Actuales Presentados en el Período Reportado

Problema Responsable Impacto (días) Acción Estado

Finalización del proyecto antes de la

fecha establecida

Marianyela,Ariana,Jenny,

Alejandra,Melvin

10 Afinar detalles para

finalizar

Rojo

10 Actividades en Proceso al Cierre del Período Reportado

WBS Actividad Base

Inicial Base Final

Inicio Real

Final Proyectado

Responsable %

8

Elaboración del prototipo

01/11/12

08/12/12

01/11/12

10/12/12

Marianyela,

Melvin,

Alejandra,

Ariana,

Jenny

85%

11 Objetivos para el Próximo Período a Reportar 7.1 Actividades y tareas a ser concluidas en el próximo período:

WBS Actividad/Tarea Responsable Fecha

Finalización Estimada

Estado Comentarios

9 Arquitectura Marianyela, Ariana,Jenny, Alejandra,Melvin

10/12/12 Verde No se realizara

10 Modelo Conceptual

Marianyela, Ariana,Jenny, Alejandra,Melvin


11 Plan Pruebas Marianyela, Ariana,Jenny, Alejandra,Melvin


12 Lecciones Aprendidas

Marianyela, Ariana,Jenny, Alejandra,Melvin


37

7.2 Hitos a entregar en el próximo período:

Entregable Responsable Fecha Estimada

Aceptación

Estado Comentarios

Arquitectura Marianyela, Ariana,Jenny, Alejandra,Melvin


Modelo Conceptual Marianyela, Ariana,Jenny, Alejandra,Melvin


Plan Pruebas Marianyela, Ariana,Jenny, Alejandra,Melvin


Lecciones Aprendidas Marianyela, Ariana,Jenny, Alejandra,Melvin


38

8. Anexo Cronograma actualizado del Proyecto

39

Prototipo

1 Logo del producto y su acrónimo

Acrónimo del producto: EMF-001-12

2 Pantallas

Pantalla Tipo Tamaño Colores Formatos

Principal formulario 648;358 Borde :formulario

active caption visual

studio

Fondo :background

image

Menú: Floral white

Formato del

texto:

Segoe UI;

10pt

Ingreso al

Sistema

formulario 403;220 Borde :formulario


studio

Fondo Button

Hightligh visual

studio

Formato del

texto:

Microsoft

Sans Serif;

8,25pt

Lista de

médicos y

pacientes



studio

Fondo : Button

Hightligh visual

studio

Menú: Floral white

Formato del

texto:

Microsoft

Sans Serif;

8,25pt

Ingreso de

nuevo

medico,nuevo

paciente y



studio

Fondo : Button

Formato del

texto:

Microsoft

Sans Serif;

40

editar Hightligh visual

studio

8,25pt

Analisis de

laboratorio



studio

Fondo : background

image

Formato del

texto:

Microsoft

Sans Serif;

8,25pt

Información

General



studio

Fondo : Button

Hightligh visual

studio

Formato del

texto:

Microsoft

Sans Serif;

8,25pt

Especialidades

Medicas



studio

Fondo : background

image

Formato del

texto:

Microsoft

Sans Serif;

8,25pt

2.1 Uso de la paleta de colores y tipo de letras

a) Fondo de las pantallas

La pantalla principal llevará un fondo que es representativo para la clínica, contiene una imagen, el nombre de la clínica y el nombre del proyecto. Las otras pantallas que componen el sistema llevan un fondo claro, algunas pantallas llevan imagen de fondo.

b) Fondo del título de las pantallas, color y tipo de letra

El back color utilizado es el “Control”, la tipografía para todas las pantallas es Microsoft Sans Serif, en un tamaño de 8,5pt y en color negro. El menú de la pantalla de inicio lleva la tipografía de Segoe UI, en un tamaño de 9,75pt y color negro

1. Letra de las etiquetas de los campos:

Estas llevan la tipografía de Microsoft Sans Serif, en un tamaño de 8,25pt y color negro.

2. Fondo de los campos de texto, color y tipo de letra

El fondo utilizado es blanco o “Windows”, la tipografía es Microsoft Sans Serif, en un tamaño de 8,25pt y color negro.

3. Formato de fechas y otros campos especiales (cédula, teléfono, etc.)

41

Los campos especiales como son los combo box, check box, fechas y teléfonos van en un fondo blanco con tipografía Microsoft Sans Serif, en un tamaño de 8,25pt y color negro. El formato de las fechas es dd/mm/yyyy, mientras que los teléfonos van con el formato de ___-___

4. Definición de los botones maximizar, minimizar y salir

Los botones de maximizar, minimizar y salir están ubicados como todas las pantallas en la esquina superior derecha, aparte de estos botones normales en las pantallas, tenemos un botón adicional para cerrar la ventana, el cual esta ubicado en la esquina inferior derecha.

5. Color y tipo de letra al pie de la pantalla

No aplica para nuestras pantallas.

42

2.2 Tipos de Botones

Tipo de botón

Función Presente en Imagen Formato Vista

Salir

Permite cerrar la aplicación

Pantalla principal

Segoe UI; 10pt

Ingresar Disponible

para ingresar a la aplicación

Login

Microsoft Sans Serif; 8,25pt

Aceptar Por medio de este botón podemos aceptar la operación correspondiente

Paciente, médico, modificar médico y paciente, Análisis de lab. ,Información General, Nuevo Ingreso, Especialidades Medicas, Editar.


Editar Icono que permite editar los diferentes datos

Lista Médicos y Pacientes


Nuevo Opción para crear un nuevo elemento

Lista Médicos y Pacientes


Eliminar Permite borrar algún dato presente en cualquier pantalla en un “Data Grid View”

Lista Médicos y Lista Pacientes

No aplica.

Cerrar Se cancela la operaciónSe cierra la aplicación

Editar pantallas, Espacialidades Medicas, Información Medica General, Análisis de Laboratorio, Médicos, Modificar,

Microsoft Sans Serif;8,25pt

43

Pacientes.

Buscar Permite buscar la información de algún paciente

Expediente Medico


Navegar Sirve para seleccionar algún paciente.

Expediente Medico


Seleccionar

Permite seleccionar algún dato presente en un “Data Grid View”

Lista de Búsqueda


44

2.3 Formularios de las pantallas

Se requiere detallar el contenido de las principales pantallas que se utilizarán en el nuevo sistema que se desarrollará

Código login Nombre del Objeto login

Tipo del Objeto(*) Formulario

Tamaño del Objeto(*) 403;220

Posición del Objeto (*) Central

Descripción del Objeto Pantalla donde se ingresará la contraseña y usuario

para la utilización de la aplicación, la cual tendrá

la capacidad de validar los datos.

Propuesta de la pantalla:

Observaciones del usuario No aplica

Revisado por: Alejandra

Flores

Aprobado por: Marianyela

Magallón

Código Frm_principal Nombre del Objeto Principal


Tamaño del Objeto(*) 648,358

Posición del Objeto (*) Toda la pantalla

Descripción del Objeto

En esta pantalla principal se presenta el menú de

aplicaciones en diferentes pestañas, contenidos en

el software y el nombre del mismo, así como el

nombre de la empresa que hace uso del sistema.

45

Propuesta del reporte:

Observaciones del usuario No aplica


Flores

Aprobado por: Marianyela Magallón

46

Código Frm_lista_médicos Nombre del Objeto Lista de Médicos




Descripción del Objeto Pantalla donde se despliega la lista de médicos y su

información. Además nos permite re-direccionarnos a

otras pantallas, ya sea para modificación de datos,

ingresos nuevos o eliminación.

Es generada al escoger en el menú principal:

Administración y en el submenú: médicos.


Observaciones del usuario No Aplica


Flores


47

Código Frm_lista_pacientes Nombre del Objeto Lista de Pacientes




Descripción del Objeto Pantalla donde se despliega la lista de pacientes y su

información. Además nos permite re-direccionarnos a

otras pantallas, ya sea para modificación de datos,

ingresos nuevos o eliminación y ver el historial médico

del paciente.

Es generada al escoger en el menú principal:

Administración y en el submenú: pacientes.




Flores


48

Código Frm_pacientes Nombre del Objeto Nuevos Ingresos


Tamaño del Objeto(*) 467, 413


Descripción del Objeto Esta pantalla nos permite ingresar a nuevos pacientes

al sistema y su información personal y necesaria para

su historial.

Es desplegada al elegir en la lista de pacientes el icono

de “Nuevo”.




Flores


49

Código Frm_mod_medicos Nombre del Objeto Editar




Descripción del Objeto Esta pantalla se encarga de la modificación de médicos

en el sistema.

Al elegir el ícono de editar nos despliega esta pantalla.




Flores


50

Código Frm_editar Nombre del Objeto Editar




Descripción del Objeto Esta pantalla se encarga de la modificación de

pacientes en el sistema.

Al elegir el ícono de editar nos despliega esta

pantalla.

Propuesta del

reporte:

Observaciones del usuario

No Aplica

Revisado por: Alejandra Flores Aprobado por: Marianyela Magallón

51

Código Frm_exp_med Nombre del Objeto Expediente Médico




Descripción del Objeto Este formulario permite hacer la búsqueda de

pacientes, dándonos la opción de escoger entre las

diferentes pestañas por información personal,

información médica general, especialidades médicas

y análisis de laboratorio.

Esta pantalla será desplegada al elegir en el menú la

opción de consultas.



Revisado por: Alejandra Flores Aprobado por: Marianyela Magallón

52

Código Frm_búsqueda Nombre del Objeto Búsqueda




Descripción del Objeto Esta pantalla despliega la lista de pacientes y nos

permite la selección del paciente que queremos buscar.

Al darle click al botón buscar de la pantalla expediente

médico, nos presentará esta pantalla.




Flores


53

Código Frm_laboratorio Nombre del

Objeto

Análisis de Laboratorio




Descripción del Objeto Este formulario ingresa los tipos de análisis realizados

al paciente, observaciones, diagnóstico ,resultado y el

Médico encargado. Esta pantalla se desplegara al

elegir la pestaña de análisis en la pantalla de

expediente médico.




Flores


Código Frm_esp_med Nombre del Objeto Especialidades Médicas

54




Descripción del Objeto Esta pantalla es desplegada al escoger la pestaña de

especialidades médicas que aparece en la ventana de

expediente médico. Nos permite ver el médico y su

especialidad, así como los síntomas del paciente, el

diagnóstico y el tratamiento que debe tomar. Esta

pantalla se desplegara al elegir la pestaña de

especialidades médicas en la pantalla de expediente

médico.




Flores


55

Código Frm_inf_gral Nombre del

Objeto

Información Médica General




Descripción del Objeto Se ingresan los datos médicos del paciente, por

ejemplo la presión, peso, masa corporal, si

consume o no algún tipo de drogas, tipo de dieta y

medicamentos. Esta pantalla se desplegara al

elegir la pestaña de información médica general

en la pantalla de expediente médico.




Flores


56

2.3.1 Tipos de Objeto

Se describen los principales tipos de pantallas a utilizar, entre ellas: a) Pantalla de Acceso: Este objeto hace una validación para que el usuario pueda o

no ingresar al sistema por medio de un login y una contraseña. b) Menú del sistema: por medio de este objeto el usuario podrá ver las diferentes

pantallas que tiene el sistema y así ver o introducir información según lo requiera. c) Pantallas de mantenimiento: En la mayoría de las pantallas el usuario tendrá que

insertar, actualizar y eliminar la información que tenga la base de datos. d) Pantallas de consulta: Con estas pantallas el usuario podrá ver toda la información

que fue ingresada y que ya está almacenada en la base de datos. e) Pantallas de consultas y generación de reportes: por medio de este objeto el

usuario podrá ver o mostrar un reporte de las actividades de la empresa.

2.3.2 Tamaños de las pantallas

La mayoría de las pantallas tendrán un tamaño de 720, 457. Excepto estas pantallas tendrán diferentes tamaños como las siguientes: -Pantalla para ingresar al médico: 467, 413. -Pantalla de Login: 403, 220. -Pantalla Principal: 648, 358.

2.3.3 Posición de los objetos

Todos los objetos estarán ubicados en el centro de la pantalla del usuario.

3 Reportes Se requiere detallar el contenido de los principales reportes que se utilizarán en el nuevo sistema que se desarrollará.

Código AJM679 Nombre del Objeto Pantallas de consulta

Reporte

Descripción del Objeto Con estas pantallas el usuario podrá ver toda la información que fue ingresada y que ya está almacenada en la base de datos. Pantallas de consultas y generación de reportes: por medio de este objeto el usuario podrá ver o mostrar un reporte de las actividades de la empresa


57

Observaciones del usuario

Revisado por: Melvin Jiménez

Aprobado por: Jeny Sandoval

58

Plan de Pruebas

59

Introducción

Este documento constituye el informe de ¡Error! Utilice la ficha Inicio para aplicar

Portada Informe al texto que desea que aparezca aquí. del proyecto Electronic Medical

File.

La prueba formal de productos de software no ha sido hasta el momento una de las

prácticas más comunes en la mayor parte de los proyectos informáticos de nuestro entorno.

Esta situación se puede deber a una falta de conocimientos al respecto y a una visión

simplificada de la importancia que representan en el ciclo productivo. Erróneamente la

prueba de productos de software se ha visualizado como la ejecución en repetidas ocasiones

de un programa, pero sin una estrategia o plan que guíe el proceso a lo largo de la gran

cantidad de opciones posibles en un entorno real.

Para efectos de unificar criterios al respecto, conviene observar una definición comúnmente

aceptada del proceso de prueba.

“Una prueba es el proceso de analizar un elemento de software para detectar

diferencias entre las condiciones existentes y las requeridas (es decir, errores o

desviaciones) y evaluar las características del elemento de software”.

Normalmente se toma como una prueba el proceso de ejecutar un programa con el

propósito de encontrar un error o anomalía. Al proceso de prueba se asocia la necesidad de

crear casos de prueba, los cuales se interesan por documentar las entradas, proyectar los

resultados esperados y las condiciones de ejecución de un programa sujeto de prueba.

Al respecto de estos casos de prueba, las siguientes afirmaciones representan paradigmas

fundamentales:

Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error

no descubierto hasta entonces.

Una prueba tiene éxito si descubre un error no detectado hasta entonces.

La aplicación de un caso de prueba puede mostrar la existencia de errores pero nunca

garantizará la inexistencia de los mismos.

El fin último de las pruebas no es “certificar” que el producto de software esté libre de

errores. Esto se debe a que hay limitaciones fundamentales en los procesos de prueba, pues

aún utilizando los métodos más sofisticados de pruebas no se puede establecer total

certidumbre respecto de la ausencia de errores, algo que sólo puede ser garantizado

mediante el empleo de métodos formales para el desarrollo de software. Por ello, las

pruebas deben enfocarse en lograr un nivel razonable de confianza respecto de la

correctitud del software, el cual estará acorde con la criticidad de la información, el grado

de utilización y la complejidad de los procesos.

Además de la dimensión de correctitud, las pruebas son la única manera de establecer si un

sistema es fácil de utilizar, eficiente, completo y tolerante a fallas, entre otras

características.

60

11.1 Tipos de pruebas

Existe una amplia variedad de tipos de pruebas que pueden aplicarse sobre los productos de

software. Las pruebas son de dos tipos fundamentales:

Pruebas de “caja blanca”: Son pruebas de carácter interno, que requieren conocer

los detalles de programación para así poder probar cada uno de los diferentes caminos

o condiciones involucrados en un proceso. También se conocen como pruebas

estructurales.

Pruebas de “caja negra”: Estas enfatizan los resultados y relaciones que tiene un

proceso con su entorno, y no la estructura lógica interna del proceso.

Desde el punto de vista práctico, es sumamente difícil establecer procedimientos basados

en pruebas del tipo “caja blanca”, pues son muy costosos, requieren de una cantidad

considerable de tiempo y el apoyo de herramientas de análisis de software caras y

sofisticadas. No obstante, es recomendable trabajar con algún nivel de pruebas de esta

naturaleza para algunos procesos críticos (típicamente enfocándose en segmentos aislados

de lógica: subrutinas, procedimientos con estructura delicada y cálculos complejos, jobs

con mucha funcionalidad).

Dadas las características, prácticas y económicas, de la mayoría de los sistemas, es más

común que las pruebas dominantes se basen en esquemas de “caja negra”, las cuales

pueden ser aplicadas tanto por personal técnico como usuario.

11.2 Niveles de pruebas

La forma en que se ejecuten las pruebas dependerá de manera directa del nivel en que se

estén aplicando. Para este proyecto específicamente se han identificado tres niveles de

prueba que deben efectuarse.

Pruebas de unidades (prueba técnica)

Este es el nivel básico de prueba. Es realizado por personal técnico, generalmente el

autor de la unidad o actualización. Entendemos por unidades las agrupaciones más

pequeñas de software que tienen, por sí mismas, una funcionalidad operativa (programa,

componente, transacción). Este nivel de prueba tiene como objetivo la eliminación de las

inconsistencias de tipo técnico, como lo son: errores en cálculos, fallas en la interfaz de

la unidad, inconsistencias en el cumplimiento de los estándares de programación, fallas

en la actualización de las estructuras de datos o en el despliegue de información.

Pruebas de Regresión

Intentan descubrir nuevos errores y sus causas, carencias de funcionalidad, o

inconsistencias funcionales con respecto al comportamiento esperado del software;

básicamente estas pruebas se utilizan al realizar cambios o mejoras en una aplicación, en

ocasiones es probable que el cambio realizado afecte la aplicación en elementos

relacionados que no tengan que ver directamente con los ajustes realizados, por eso es

conveniente realizar pruebas de módulos o subsistemas que tengan relación con la

funcionalidad que se mejoró o actualizó. Estas pruebas son ejecutadas de manera

conjunta por técnicos y usuarios. Al ejecutar estas pruebas interesa principalmente la

verificación del la incorporación del cambio de acuerdo con la solicitud y la generación

61

de resultados correctos. Para la elaboración de los casos de pruebas y la ejecución de los

mismos se requiere que el usuario cuente con el conocimiento de la aplicación antes del

cambio y conozca el nuevo funcionamiento con la incorporación de las actualizaciones

solicitadas.

Pruebas de módulos o subsistemas

Los módulos o subsistemas son agrupaciones lógicas de unidades; al decir lógicas

estamos estableciendo que las transacciones o unidades que componen determinado

módulo presentan algún nivel de afinidad funcional. Estas pruebas son ejecutadas de

manera conjunta por técnicos y usuarios. En cuanto a lo técnico interesa principalmente

la verificación de la integración de las diferentes unidades (probadas previamente), y la

homogeneidad y consistencia del módulo. A la parte usuaria le interesará especialmente

la generación de resultados correctos por parte de estos módulos, así como validar que

los resultados estén acordes con las necesidades de información atendidas por el sistema.

Al concluir las pruebas de módulos se sabrá con bastante certeza la incidencia de

defectos remanentes en el sistema y el grado de satisfacción de requerimientos que éste

presenta.

Cada uno de estos niveles de prueba requiere de habilidades y énfasis diferentes. La

realización de los distintos niveles de prueba de manera rigurosa y ordenada disminuye la

posibilidad de enfrentar situaciones de difícil resolución en el ambiente de producción.

11.3 El Plan de Pruebas

Los fundamentos anteriores vienen a respaldar la importancia de formular un plan de

pruebas para los diferentes productos de software que comprende Electronic Medical File y

que en el mismo se plasme tanto la visión técnica como usuaria de los casos de prueba que

deben ser aplicados.

Este documento tiene el objetivo de servir como base para la formulación detallada de la

aplicación de pruebas al software, indicando los niveles de prueba que se aplicarán, la

calendarización del proceso, la organización del equipo de pruebas y las consideraciones

más relevantes para una ejecución exitosa del proceso.

Como se indicó anteriormente este documento es el marco de referencia para concretar un

plan detallado, en el cual se complementa la experiencia usuaria con la experiencia técnica.

Esta labor es intensa y fundamental para lograr un proceso de prueba que garantice una

puesta en producción con el mínimo de inconvenientes en el software.

62

12 descripción del proceso de prueba

Para comprender el proceso de prueba que de manera específica se aplicará para el

Electronic Medical File, a continuación se presenta la descripción desglosada de cada uno

de los niveles que comprende este proceso.

12.1 Estrategia de prueba

Como se ha indicado anteriormente, cada nivel de prueba tiene su propia orientación, así

como herramientas y participantes diferentes. Las pruebas iniciales o técnicas se enfocan a

la comprobación de los componentes fundamentales de manera individual, luego se verifica

el correcto funcionamiento de la opción modificada y por último se verifica el tamaño del

objeto de prueba a módulos o submódulo (agrupación de funciones afines) para verificar

que la actualización no haya afectado funcionalidades relacionadas.

Este esquema de incrementalidad se fundamenta en el principio de que al unir piezas

correctas, las pruebas de mayor nivel se concentran en elementos de integración entre

piezas cada vez de mayor tamaño, con lo cual se minimiza la complejidad del proceso.

Para lograr un proceso efectivo, cada uno de estos niveles de prueba debe mantenerse

apegado a los siguientes principios:

12.1.1 Formalidad del proceso

El proceso debe mantener una aplicación formal de las diferentes pruebas, respetando la

organización y herramientas definidas. La participación multidisciplinaria en este proceso

obliga a mantener un único esquema de trabajo con una dirección clara para todos sus

participantes. En este aspecto, el grupo de prueba debe conocer y aplicar los lineamientos

establecidos en lo que respecta a: los requisitos para iniciar cada prueba, la forma como

debe ejecutar cada prueba, el mecanismo de reporte de los hallazgos (inconsistencias o

mejoras) y la verificación posterior de los ajustes aplicados.

Este principio implica la designación de un responsable del proceso de prueba que vele y

garantice el respeto a las reglas de prueba que se estipulan en este documento.

12.1.2 Agilidad en la comunicación

En el punto anterior se indicó la importancia de la formalidad del proceso, lo cual debe

integrarse armónicamente con la agilidad en la comunicación que requiere cada nivel de

prueba. Esta agilidad cubre: la resolución oportuna de consultas de orden técnico sobre

cada componente en prueba, el reporte inmediato de los hallazgos, el soporte técnico

requerido para la ejecución de prueba y re-prueba, la investigación particular sobre casos de

prueba poco comunes y la obtención de información para establecer comparaciones o

sustento que requiera cada hallazgo.

Esta agilidad no implica la eliminación del registro documental, pero si busca que el

intercambio de información no requiera procesos de transcripción (por aspectos de forma) o

de intermediarios entre la fuente y el receptor. Esta condición requiere de un fuerte

63

compromiso y la asignación de facultades para el equipo de trabajo asignado al proceso de

prueba.

12.1.3 Fondo sobre la forma

Una tendencia en los proceso de prueba poco estructurados es la concentración en los

aspectos de forma versus los elementos de fondo. Si bien es cierto los elementos de forma

pueden afectar el máximo aprovechamiento de una solución informática, no son estos los

que mayores implicaciones presentan al iniciar los procesos de producción.

El equipo asignado para las pruebas debe comprender y diferenciar los elementos de forma

y de fondo en los hallazgos que localice, y debe colocar énfasis en la resolución de estos

últimos.

Este mismo principio se aplica para la documentación de los hallazgos, pues es

indispensable que se documenten, pero no requieren de formatos o requisitos de forma

minuciosos, pues en todo caso corresponden a productos intermedios cuyo objetivo es

permitir el ajuste de la solución informática.

12.1.4 Ambiente controlado

El ambiente en donde se ejecuten las pruebas requiere estar bajo el mayor nivel de control

posible, esto implica: aislado de la operación rutinaria, con recursos informáticos (equipos

y red) que no contaminen los resultados, con dominio de la información contenida en la

base de datos y de los que se ingresan, con la posibilidad de repetir un proceso de prueba

bajo condiciones idénticas y con personal continuo y conocedor del proceso de prueba.

12.1.5 Integración del equipo de prueba

Una de las claves para lograr un proceso de pruebas efectivo es la integración de equipos

multidisciplinarios, en donde se verifican simultáneamente las diferentes dimensiones que

conlleva una solución informática. Esta integración se logra al asignar un equipo continuo

de pruebas con personas de diferentes especialidades con una organización y roles

claramente definido. El nivel de concentración que requiere este equipo implica que este

proceso debe ser visualizado como una actividad fundamental y no como secundaria en su

asignación laboral.

12.1.6 Actitud constructiva para la prueba

La actitud que asuma y transmita el equipo de pruebas es fundamental para alcanzar un

proceso efectivo. El objetivo de la prueba es contribuir a obtener un mejor producto de

software, no destruirlo o degradarlo en función de la detección de inconsistencias. Sobre

este aspecto, tanto los responsables del proceso de prueba como los mecanismos de

intercambio de información deben mantenerse alineados con la actitud constructiva entre

probadores y constructores.

64

12.2 Niveles de prueba

A continuación se describen los tres niveles de prueba que se sugiere se apliquen para

Electronic Medical File

Pruebas técnicas

Objetivo Lograr la detección de los errores que presenten los

componentes de menor nivel.

Descripción del proceso Cada uno de los desarrolladores de software es responsable de

la verificación de estándares antes de dar por concluida la

programación de cualquier componente. Posteriormente, el

Líder Técnico aplicará el chequeo de calidad funcional en

donde se evalúan las especificaciones de diseño y el estándar

de interfaz, esto por medio de recorridos e inspecciones.

En caso de detectar inconsistencias, se le trasladarán al

desarrollador responsable del componente en cuestión para su

corrección y re-prueba posterior.

Herramientas 1. Electronic Medical File

2. Informe de Especificación.

3. Documentos de Casos de Uso.

4. Estándares de desarrollo.

5. Recorridos e inspecciones sobre piezas de software.

Responsable Equipo desarrollador

Resultado esperado Componentes de menor nivel cumpliendo a cabalidad con el

estándar definido, la funcionalidad requerida y la lista de

cotejo definida para cada tipo de componente.

12.2.1 Pruebas de regresión

Objetivo Asegurar el comportamiento y resultados de cada uno de los

componentes u opciones donde se aplicó una mejora o un

cambio.

Descripción del proceso Cada opción, funcionalidad o componente se debe verificar

según lo especificado en la solicitud de cambio.

Apoyados en los casos de prueba elaborados, la idea es probar

la aplicación dando énfasis a las funcionalidades en donde se

aplicaron mejoras, no obstante, se recomienda probar

parcialmente aquellas opciones del sistema que no se les

65

aplicó ningún cambio con el objetivo de detectar posibles

fallos producto de las actualizaciones aplicadas.

La composición de cada caso de prueba incluye:

1. Identificación única del caso.

2. Responsable del caso.

3. Objetivo del caso.

4. Condiciones previas requeridas.

5. Secuencia de transacciones (transacción, datos de

entrada y resultado esperado y observaciones).

El desarrollo de los casos de prueba debe considerar:

secuencias comunes, secuencias atípicas, datos típicos,

datos atípicos, datos en los límites permitidos y repetición

de secuencias, entre otras.

Con los casos desarrollados y el entorno preparado (equipos,

datos y formularios) se procede a ejecutar las secuencias

descritas en cada caso y a recopilar la información sobre los

hallazgos obtenidos.

Estos hallazgos se categorizan de la siguiente manera:

Inconsistencias en funcionalidades.

Inconsistencias en aspectos de forma.

Mejoras potenciales.

En función de los resultados obtenidos en aspectos funcionales

para cada caso de prueba, el equipo de prueba debe determinar

si se requiere la reaplicación del caso una vez reparadas las

inconsistencias detectadas.

Tanto para la aplicación inicial de los casos de prueba como de

la eventual repetición de los mismos, se debe tener presente la

necesidad de mantener un ambiente controlado, pues la

ejecución misma de las pruebas modifica el entorno y

condiciones previas establecidas.

La prueba de cada opción concluye en el momento que el

equipo de prueba verifica que la totalidad de inconsistencias

detectadas han sido reparadas por el equipo desarrollador


2. Informe de Especificación de Mejoras.


66

4. Casos de prueba, para cada uno de los diferentes

escenarios considerados como relevantes para el

módulo en prueba (Ver Anexo 2 – Formato para Casos

de Prueba)

5. Formato para reporte de hallazgos (Ver Anexo 3 –

Reporte de Hallazgos).

Responsable Equipo de prueba asignado por la empresa para las tareas de

ejecución y coordinación del proceso de prueba. Los

desarrolladores y analistas de la empresa desarrolladora

deberán apoyar este proceso con su conocimiento del producto

desarrollado, tanto en labores de asesoramiento, corrección de

inconsistencias detectadas y guía en elementos técnicos. (Ver

capítulo 4 – Organización y Roles para el Proceso de Prueba)

Resultado esperado Opciones actualizadas y probadas tanto a nivel interno como

de su interfaz externa.

12.2.2 Pruebas de módulos

Objetivo Asegurar el comportamiento y resultados de cada uno de los

módulos en los cuales se actualizó o se mejoró alguna

funcionalidad o procesamiento; de manera que los flujos de

información de entrada y salida muestren el comportamiento

definido de forma correcta.

Descripción del proceso De acuerdo con los requerimientos, en esta etapa se realizará

las pruebas modulares:

La idea es efectuar un recorrido sobre el módulo. Este

recorrido tiene como objetivo evaluar el correcto

funcionamiento y los resultados de toda la funcionalidad del

módulo incluyendo las opciones que no se les ha realizado

ningún cambio, esto para comprobar que las actualizaciones

aplicadas no afectaron la ejecución y los resultados en las

opciones relacionadas y además estandarizar el conocimiento

del equipo de trabajo sobre las actualizaciones y el producto

final.

Para este efecto es necesario crear casos de prueba que

permitan comprobar el correcto funcionamiento de los

módulos en cuestión. La composición de cada caso de prueba

incluye:

1. Identificación única del caso.

2. Responsable del caso.

3. Objetivo del caso.

4. Condiciones previas requeridas.

5. Secuencia de transacciones (transacción, datos de

67

entrada y resultado esperado y observaciones).

En los casos de prueba la secuencia de transacciones se refiere

al grupo y orden de las transacciones que deben ser utilizadas

para verificar las interrelaciones en el módulo y fuera de él.

Eventualmente esta secuencia de transacciones puede

corresponder a una única transacción con diferentes datos y

condiciones de entrada.

Sobre el desarrollo y aplicación de los casos de prueba, debe

aplicarse el concepto de incrementabilidad., bajo el siguiente

orden sugerido:

Transacciones de mantenimiento simple.

Transacciones de mantenimiento de entidades con

referencia a parámetros.

Transacciones de tramitación que requiere de la

existencia de entidades de parámetros y bases de

información.

Transacciones que implican la ejecución de procesos

masivos.

Consultas y reportes relacionados con la información

registrada en el sistema

Transacciones que implican la generación de procesos

de respaldo y descarga de archivos.

El desarrollo de los casos de prueba debe colocar especial

cuidado en la ejecución de procesos masivos, pues estos

implican la actualización de múltiples estructuras de datos y

poca visualización interactiva.

Con los casos desarrollados y el entorno preparado (equipos,

datos y formularios) se procede a ejecutar las secuencias

descritas en cada caso y a recopilar la información sobre los

hallazgos obtenidos.

Estos hallazgos se categorizan de la siguiente manera:

Inconsistencias en funcionalidades.

Inconsistencias en aspectos de forma.

Mejoras potenciales.

En función de los resultados obtenidos en aspectos funcionales

para cada caso de prueba, el equipo de prueba debe determinar

si se requiere la reaplicación del caso una vez reparadas las

inconsistencias detectadas.

68

Tanto para la aplicación inicial de los casos de prueba como de

la eventual repetición de los mismos, se debe tener presente la

necesidad de mantener un ambiente controlado, pues la

ejecución misma de las pruebas modifica el entorno y

condiciones previas establecidas.

La prueba de cada módulo concluye en el momento que el

equipo de prueba verifica que la totalidad de inconsistencias

detectadas han sido reparadas por el equipo desarrollador.

Posteriormente, el equipo de prueba debe recopilar las mejoras

potenciales detectadas, las cuales formarán parte del informe

de resultados del proceso de pruebas.


2. Informe de Especificación.


4. Casos de prueba, para cada uno de los diferentes

escenarios considerados como relevantes para el

módulo en prueba (Ver Anexo 1 – Formato para Casos

de Prueba)

5. Formato para reporte de hallazgos (Ver Anexo 2 –

Reporte de Hallazgos).

Responsable Equipo de prueba asignado por la empresa para las tareas de

ejecución y coordinación del proceso de prueba. Los

desarrolladores y analistas deberán apoyar este proceso con su

conocimiento del producto desarrollado, tanto en labores de

asesoramiento, corrección de inconsistencias detectadas y guía

en elementos técnicos. (Ver capítulo 4 – Organización y Roles

para el Proceso de Prueba)

Resultado esperado Módulos de la solución informática probados de manera

completa, tanto a nivel interno como de su interfaz externa.

12.3 Seguimiento del proceso de pruebas

Para garantizar la efectividad del desarrollo del proceso de pruebas, se ha desarrollado una

herramienta (ver anexo 3 – Detalle de pruebas a Realizar) que sirve como mecanismo para

el registro y control de los casos de pruebas diseñados y seleccionados por el equipo de

pruebas, de manera que se pueda obtener, en cualquier momento, un estado del desarrollo y

evolución de todos y cada uno de los casos a probar. La herramienta consiste en una

pequeña base de datos que se utilizará como bitácora para registrar todas las observaciones

pertinentes con el caso y los resultados obtenidos al momento de la ejecución de las

pruebas. Debido al alto volumen de casos de pruebas que se deberán desarrollar, es de

69

especial importancia el uso de este mecanismo ya que por este medio, los responsables del

desarrollo de pruebas, podrán asegurarse del cumplimiento de las actividades establecidas

en el cronograma del proyecto.

70

13 Calendarización del proceso de prueba

A continuación se presenta el cronograma de trabajo que se propone como base para el

desarrollo del proceso de pruebas. Se enfatiza que debe entenderse como un cronograma

base, pues en función de los recursos asignados y de la cantidad de pruebas que se

consideren necesarias, los tiempos y tareas aquí indicadas pueden sufrir ajustes, aunque no

se visualizan cambios en la filosofía de prueba y secuenciación de tareas que se propone.

# Act. Descripción de la Actividad Fecha Inicio

(dd/mm/aaaa) Fecha Final

(dd/mm/aaaa) 58 Pruebas 25/10/2012 09/12/2012

59 Desarrollar el Plan de Pruebas 25/10/2012 26/10/2012

60 Presentar el Plan de Pruebas 26/10/2012 26/10/2012

61 Validar el Plan de Pruebas 31/10/2012 31/10/2012

62 Ajustar el Plan de Pruebas 31/10/2012 31/10/2012

63 Aprobar Plan de Pruebas 31/10/2012 02/11/2012

64 Crear Casos de Prueba 02/11/2012 09/11/2012

65 Entregar Casos de Prueba 09/11/2012 09/11/2012

66 Verificar Casos de Prueba 10/11/2012 16/11/2012

67 Integrar Casos de Prueba 17/11/2012 18/11/2012

68 Preparación de Ambiente de Pruebas 25/11/2012 28/11/2012

69 Aplicar pruebas a nivel de funcionalidad Individual 28/11/2012 30/11/2012

70 Aplicar pruebas de regresión 30/11/2012 02/12/2012

71 Aplicar pruebas de integración de módulos 02/12/2012 06/12/2012

72 Aplicar ajustes al software producto de las pruebas 06/12/2012 07/12/2012

73 Preparar y Presentar Informe de Pruebas 07/12/2012 09/12/2012

71

14 Organización y roles para el proceso de prueba

Una de las características más importantes del proceso de prueba es la necesidad de formar

equipos multidisciplinarios para llevar a cabo esta importante tarea. Esta condición implica

un cuidadoso análisis sobre los miembros del equipo de prueba y como se organizarán de

manera que el proceso se ejecute de la manera más efectiva posible.

Como mínimo, los siguientes roles deben estar presente en el equipo de pruebas:

14.1 Coordinador del equipo de prueba

Este recurso se encargará de la coordinación del equipo de pruebas asignado para este

producto de software, específicamente en lo que corresponde a pruebas modulares y

pruebas de integración. Concretamente a este recurso le corresponde:

1. Asignación de tareas al resto del equipo.

2. Seguimiento del plan de trabajo establecido.

3. Velar por la asignación oportuna de los recursos humanos y materiales requeridos

para el proceso de prueba.

4. Recopilación de resultados del proceso de prueba.

5. Informar a la comisión de seguimiento del proyecto sobre los avances realizados.

6. Controlar la aplicación de los principios del proceso de prueba que se concretan en

este documento.

7. Elaborar el informe de resultado de las pruebas.

14.2 Especialista técnico

Este recurso se encargará de la dimensión técnica del proceso de prueba, en apoyo al área

funcional. Debe ser preocupación de este recurso:

1. Verificar los elementos internos del sistema en cada ejecución de pruebas

modulares e integrales, incluyendo la actualización de la base de datos, el

rendimiento, la seguridad y el apego al diseño del software.

2. Apoyar al área funcional en la compresión del producto de software.

3. Desarrollar las tareas de preparación del ambiente de pruebas, específicamente en

los elementos de orden técnico.

4. Desarrollar las tareas técnicas que permitan mantener un ambiente de pruebas

controlado, lo que incluye la generación de respaldos, recuperaciones de respaldos y

las verificaciones de integridad.

72

14.3 Especialista en soporte técnico

Dada la importancia del factor tiempo en la ejecución de estas pruebas, se considera

necesaria la disponibilidad del conocimiento especializado en los elementos de plataforma

que utiliza el producto de software (red, sistema operativo, base de datos). Este recurso

tiene como funciones:

1. Apoyar los procesos de preparación del ambiente tecnológico en que se ejecutarán

los procesos de prueba.

2. Mantenerse en disponibilidad para apoyar la resolución de inconvenientes asociados

con elementos de la plataforma tecnológica utilizada.

3. Apoyar la interpretación de los resultados obtenidos, especialmente en lo que

respecta a pruebas de orden técnico.

14.4 Especialista del área funcional

Este recurso tiene la responsabilidad de aportar la dimensión funcional al proceso de

prueba, lo que lo convierte en el eje principal de esta actividad. Sus funciones en este

proceso son:

1. Preparar los casos de prueba modular e integral, específicamente en lo que respecta

a los elementos funcionales que deben ser probados.

2. Aportar su conocimiento funcional para interpretar los resultados obtenidos, así

como para transmitir las necesidades de ajuste al equipo desarrollador.

3. Desarrollar las tareas de preparación del ambiente de pruebas, en lo que respecta a

información, materiales documentales, personal experto en temas específicos del

área funcional y enlaces con unidades fuera del departamento de auditoría.

4. Apoyar el mantener un ambiente de pruebas ordenado, al observar la ejecución de

los casos de prueba desarrollados.

14.5 Analista de negocio

Este recurso tiene el conocimiento técnico y funcional del producto de software, pues es

parte activa de la creación de la solución, como tal sus tareas en este proceso son:

1. Fungir como el canal primario para el contacto entre el equipo de pruebas y los

analistas

2. Soportar al área técnica y funcional en los elementos de uso y alcances de cada

componente sometido a pruebas.

3. Apoyar los procesos de preparación del ambiente de pruebas, específicamente con

su conocimiento sobre el producto de software.

4. Apoyar el proceso de desarrollo de los casos de prueba.

73

5. Soporte inmediato durante la ejecución de los casos de prueba, con el fin específico

de conocer los hallazgos y canalizar la resolución de inconsistencias.

14.6 Desarrollador del producto

Este recurso tiene el conocimiento del detalle técnico de los componentes del producto de

software, por lo que sus funciones en este proceso se concentran en:

1. Llevar a cabo los ajustes que requiera el software en función de los hallazgos que

obtenga el grupo de pruebas.

2. Ejecutor titular del proceso de pruebas técnicas.

3. Apoyar la resolución de consultas sobre aspectos técnicos del producto de software.

4. Apoyar la preparación del ambiente de pruebas en lo que a elementos técnicos se

refiere.

5. Mantener el control del versionamiento del software, en función de los ajustes

aplicados durante el proceso de pruebas.

14.7 Asesor metodológico

Este recurso tiene como fuerte su conocimiento sobre los elementos metodológicos que se

incluyen en el proceso de prueba, de manera específica sus tareas son:

1. Resolver las dudas de orden metodológico que se le presenten al equipo de prueba

durante las diferentes fases de este proceso.

2. Mantener la atención sobre el proceso, para así garantizar el apego a los

lineamientos establecidos en este plan.

3. Asesorar en la elaboración de los casos de prueba al equipo asignado.

4. Evidenciar los riesgos potenciales que atenten contra el proceso de prueba.

5. Coordinar la asignación de recursos y tareas que le correspondan la empresa

desarrolladora como parte del proceso de pruebas.

Es importante aclarar que las descripciones anteriores indican el término “recurso” en

singular, sin embargo esto no indica que es una única persona la que puede ser asignada a

cada rol, sino que en función de la magnitud del trabajo, la disponibilidad de recursos y los

plazos asignados, es posible la asignación de varias personas para cumplir con cada rol. Se

hace la salvedad en el caso del Coordinador del Equipo de Pruebas, pues efectivamente este

rol se concibe como ejecutado por una única persona.

74

15 Requerimientos y consideraciones para el proceso de prueba

En suma a los elementos descritos en las secciones anteriores, a continuación se indican

una serie de requerimientos y consideraciones relevantes, enfocados hacia el logro de

proceso de pruebas efectivo y acorde con los lineamientos estipulados en este documento.

15.1 Base de datos de prueba

Uno de los elementos críticos sobre los que se ejecutarán las pruebas es la base de datos,

pues de ella dependen en buena medida la veracidad de los resultados que se obtengan.

Sobre este aspecto es clave: el establecimiento de procedimientos de respaldo y

recuperación integrados al proceso de prueba, la verificación de estado anterior y posterior

a la ejecución de secuencias de prueba, el control de los procesos de inyección masiva de

información, el control de volúmenes de información y de la integridad general de las

estructuras.

Esta responsabilidad está contenida en el rol de “Soporte Técnico” indicado en la

organización del equipo de pruebas, por lo que al momento de asignar el personal a esta

función se debe tener presente la importancia del nivel de disponibilidad y el nivel de

dominio técnico que se requiere.

15.2 Instalaciones físicas para pruebas

Las pruebas deben llevarse a cabo en un ambiente separado del de producción normal, para

evitar interrupciones que afecten el normal desempeño del proceso. Al momento de elegir

y preparar este espacio se debe considerar: cantidad de personas que participarán en el

proceso de pruebas, la cantidad de equipos requeridos, la instalación de red, espacio para

trabajo de análisis de casos, espacio para almacenar la documentación necesaria para

generar las pruebas, disponibilidad de líneas de comunicación, seguridad de acceso y

posibilidad de laborar fuera del horario normal.

15.3 Componentes tecnológicos

Los componentes tecnológicos (red, equipos, software) que se utilicen en este proceso de

prueba preferiblemente deben considerarse como de asignación exclusiva, pues por la

naturaleza de este tipo de tareas en ocasiones se hace necesario efectuar trabajos que

implican suspender el acceso al sistema en prueba. Esta situación podría afectar a cualquier

otra persona que comparta la infraestructura tecnológica con el proceso de prueba.

De preferencia, la instalación tecnológica debe acercarse en la mayor proporción posible al

ambiente en que verdaderamente operará posteriormente el sistema, pues así se obtiene

mayor garantía de enfrentar menos inconvenientes durante la puesta en producción del

producto.

75

15.4 Asignación del personal

Una consideración importante al momento de asignar el personal al proyecto es la

continuidad que debe mantener estos usuarios, tanto en el proyecto como en el proceso de

pruebas mismas. La experiencia que se genera del proceso de prueba, es en extremos

beneficiosa para el uso del sistema por parte de los usuarios finales y para los procesos de

replicación del conocimiento.

Este punto nos lleva a considerar que el personal que se asigne al equipo de pruebas tendrá

una carga importante de trabajo, incluso luego de finalizado este proceso, pues por la

experiencia y dominio de la aplicación adquiridos, sus aportes en las restantes etapas de

proyecto apoyarán una mayor probabilidad de éxito.

15.5 Instrucción previa

Es importante que el equipo que se asigne al proceso de prueba haya recibido capacitación

previa en los alcances, en las herramientas de prueba y en las funcionalidades de la

aplicación.

Se debe ubicar desde el inicio la totalidad de personal que participará en el proceso, para así

evitar la necesidad de repetir la instrucción. En el caso de ser necesaria la incorporación de

personal adicional durante el proceso, se debe tener presente que estos recursos deben

conocer las implicaciones del proceso de prueba, su metodología, la organización y

herramientas que se utilizan.

15.6 Paralelismo

Se debe tener presente que existe la posibilidad de enfrentar la prueba simultánea de

diversos componentes de sistema, los cuales incluso podrían interactuar entre sí, situación

que de no visualizarse podría afectar la ejecución del proceso de prueba. De especial

cuidado es la ejecución de procesos de actualización masiva, los cuales afectan múltiples

estructuras de datos en una sola corrida. Esta situación implica una comunicación activa

entre el personal que ejecuta las pruebas y el grupo que desarrolló el producto, para conocer

las implicaciones de cada secuencia de transacciones dentro del sistema.

76

Electronic Medical File

CERTIFICACIÓN DE FUNCIONALIDAD

Por este medio los abajo firmantes el día 10 de diciembre de 2012 en San Pedro,

Costa Rica de manera conforme certificamos que las funcionalidades del

Electronic Medical File (EMF) funcionan de acuerdo a la funcionalidad actual.

Todo lo anterior fue comprobado con la realización y validación de las Pruebas

Integrales correspondiente a la ejecución del Proyecto.

Nombre De Función Firma

Alejandra Flores Empresa Usuario Experto

Marianyela Magallón Empresa Contraparte Tecnología

Ariana Cerdas Empresa Contraparte Tecnología

Jenny Sandoval Proveedor Contraparte

Empresa

77

Solicitud de cambio

Fecha 1-12-2012 Requerimiento Nº

No

funcional

#6

Tipo de mantenimiento x Correctivo Evolutivo Regulativo

Uso Local Negocio

Importancia x Alta Media Baja

Correctivo: Corregir errores

Evolutivo: Nueva funcionalidad para mejorar la calidad Regulativo: Modificación, incorporación, eliminación por cambios

1. Detalle de la solicitud

Área solicitante Administración de Proyectos

Nombre Solicitante Humberto Araya

Nombre del Proyecto Electronic Medical File

2. Detalle del Cambio

Requerimiento Hardware (25 pc’s y 1 Servidor)

Descripción y alcance del requerimiento

Se requerirán dos servidores en lugar de uno para mayor eficiencia del sistema.

Justificación del requerimiento

Mantener la integridad de la información almacenada. Eficiencia y seguridad del funcionamiento del sistema en todo

momento.

Beneficios esperados

Un más alto rendimiento y asegurar el funcionamiento del sistema en todo momento. En caso de que un servidor sufriera

algún daño, el otro servidor mantendrá la integridad del sistema y sus datos.

Observaciones

Dar seguimiento inmediato y conseguir ambos servidores de la misma capacidad y con iguales características.

3. Aprobaciones

Nombre Rol/Perfil Firma

Humberto Araya Jefe de Administración de Proyectos Humberto A.

Maryangela Magallón Encargado del Proyecto MaryA M

78

Conclusión

Para este proyecto Electronic Medical File, se desarrolló toda la

documentación necesaria para dirigir con éxito la investigación, durante

el proceso se logró conocer gran cantidad de materia dada en el curso

que fue de gran provecho para terminar este proyecto fue indispensable

hacer estudios para completar cada uno de los pasos que se debían

seguir.

Es por esto que el proyecto contiene todas las etapas de un desarrollo de

software como la etapa de inicio donde se diseñó el perfil del producto, el logo de

la empresa, también tenemos otras etapas como la de diseño, desarrollo entre

otras, donde se trabajó con variedad de personal para que fueran haciendo cada

uno la parte que se le asigno haciendo de esta investigación un trabajo en equipo

además de que fue de gran beneficio para todos ya que se logró con el objetivo de

terminar dicho proyecto tomando en cuenta todos los requerimientos planteados

en la etapa de inicio y con este proceso se alcanzaron todas las expectativas que

se tenía sobre el curso además de aprender sobre diagramas de secuencia,

diagramas de arquitectura se tuvo que analizar en que entornó se iba a desarrollar

este proyecto de software, también se agregaron modelos conceptuales donde se

puede ver más apegado a la realidad la solución que se dio al problema que se

tenía ya que se necesitaba tener registro de todos los pacientes y doctores de la

clínica para así poder tener expedientes digítales donde la información se

mantuviera seguro y de fácil acceso para el doctor o la recepcionista, fue muy

interesante hacer una lista de los posibles riesgos que se podían presentar en este

tipo de proyectos y darles soluciones razonables, además de pensar muy bien

cada paso de la investigación antes de hacer el desarrollo del software.

Fue muy satisfactorio todo lo presentado en este sistema, ya que éste

puede ser la base de muchos proyecto más de software que sean relacionados

con clínicas o hospitales y demás entornos, los objetivos se cumplieron y la

conclusión es que este proyecto fue de gran ayuda para entender muchos

términos e información valiosa para otras investigaciones futuras.

79

Recomendaciones

Según lo aprendido durante el curso de Documentación del Software estás

son nuestras recomendaciones:

Con todos los avances que fuimos entregando semana tras semana nos

hemos dado cuenta que para trabajos de Software es muy importante siempre

llevar la documentación pertinente para que así no hayan malos entendidos entre

el cliente y la empresa desarrolladora de Software, esto con el fin de evitar futuras

apelaciones por parte del cliente en cuando se encuentre insatisfecho con el

producto generado, en donde hayan documentos que se fueron entregados al

cliente con forme sus etapas de desarrollo y para así demostrarle que desde el

principio del proyecto estos documentos se le fueron presentados y de la misma

manera iban siendo aprobados por el cliente.

Siguiendo todos estos documentos podremos lograr un desarrollo de software

exitoso lo cual dará calidad que llegar y realizar el software sin la documentación

pertinente para luego entregárselo al cliente y que a la hora de la hora no sea el

producto que este esperaba.

80

3 Glosario Incluye los términos especializados y sus respectivas descripciones.

Término Descripción Formato Relaciones con otros elementos

Rango de

valores

Reglas de validación

Password Clave para entrar al sistema

Alfanumérico Login 0-10 No usar caracteres especiales

Login Nombre de usuario para ingresar al sistema

Letras Password 0-20 No usar mayusculas

Id de paciente Número de identificación del cliente

Numérico 0-10 No usar letas ni caracteres especiales

Fechas Fechas como la de nacimiento

Numérico Id de paciente 0-30 Formato dd/mm/yyyy.

Mutas son las notas oficiales que registran lo que ocurrió en una reunión de los miembros o de los funcionarios de una organización

Entregables del proyecto

Pruebas de Testing

son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o “stakeholder”

Etapa de Implementación

y pruebas

Especificaciones son los documentos en los cuales se definen las normas, exigencias y procedimientos a ser empleados y aplicados en todos los trabajos de construcción de obras, elaboración

http://es.wikipedia.org/wiki/Stakeholder

81

de estudios, fabricación de equipos o productos software

Flujos Alternos se refieren a los pasos que

alternativamente van realizando

los actores y el sistema en el

contexto del

requisito funcional

capturado en el caso

Casos de Uso

Plan de Contingencia

instrumento de gestión para el buen gobierno de las Tecnologías de la Información y las Comunicaciones en el dominio del soporte y el desempeño

Administración de riesgos

Plataforma es un sistema que sirve como base para hacer funcionar determinados módulos de hardware o de software con los que es compatible

Especificaciones de

requerimientos no funcionales

Fiabilidad Característica de los sistemas informáticos por la que se mide el tiempo de funcionamiento sin fallos

Especificaciones de

requerimientos no funcionales

Servidor Es un equipo informático que forma parte de una red y provee servicios a otros equipos cliente

Hardware

Portabilidad capacidad de un programa o sistema de ejecutarse en diferentes

http://es.wikipedia.org/wiki/Hardware

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Compatibilidad_%28inform%C3%A1tica%29

http://www.alegsa.com.ar/Dic/programa.php

http://www.alegsa.com.ar/Dic/portabilidad.php

82

plataformas o arquitecturas con mínimas modificaciones

Rectifique Reparar, o arreglar algo descompuesto.

http://www.alegsa.com.ar/Dic/plataforma.php

http://www.alegsa.com.ar/Dic/arquitectura.php

83

Anexos En esta sección se indicará el nombre de los documentos utilizados como referencia para

complementar la información suministrada en la especificación de requerimientos.

Matriz de Estimación de Tiempos (documento que será llenado por la parte técnica)

Anexo #1

MATRIZ DE ESTIMACIÓN DE TIEMPOS

No. Actividades/Tareas Estimación de esfuerzo (en horas)

Etapa Planificación

Elaboración del Plan de Trabajo

Elaboración y entrega del plan de trabajo 15

Ajustes al plan de trabajo 3

Etapa Ejecución

Especificación y entrega de los Requerimientos

Análisis del requerimiento # 1 12

Análisis del requerimiento # 2 … 12

Ajustes al documento de especificación 6

Especificación y entrega del Diseño de los Requerimientos

Diseño del requerimiento # 1 36

Diseño del requerimiento # 2 … 36

Ajustes al documento de diseño 24

Programación de los requerimientos

Desarrollo del requerimiento # 1 840

Desarrollo del requerimiento # 2 … 840

Pruebas Técnicas (del Programador)

Ejecución de pruebas técnicas 300

Ajustes en función de las pruebas 200

Pruebas de Usuario

Soporte y ajustes de hallazgos en las pruebas de usuario 50

Elaboración de Manuales

Elaboración del manual de usuario 150

Elaboración del manual técnico 95

Elaboración del manual de instalación 30

Ajustes en función de la revisión 140

Desarrollo de la Capacitación

Preparación de la capacitación 25

84

MATRIZ DE ESTIMACIÓN DE TIEMPOS

No. Actividades/Tareas Estimación de esfuerzo (en horas)

Ejecución de la capacitación del usuario 50

Ejecución de la capacitación técnica 50

Documentación de los resultados de evaluación a los participantes

50

Instalación y entrega

Preparación de instaladores y documento de pase a producción

100

TOTAL DEL PROYECTO 3066

Modelos para la elaboración del Sistema

1. Modelo Conceptual

85

2. Modelo de Arquitectura

86

3. Modelos de Secuencia

Diagrama de Secuencia #1 Acceso al sistema

87

Diagrama de Secuencia #2 Registro de Pacientes

88

Diagrama de Secuencia #3

Registro de Médicos

89

Diagrama de Secuencia #4

Consultas al Expediente Electrónico

90

Anexo 1– Formato para Casos de Prueba

A continuación se presenta el formulario correspondiente al formato de los casos de prueba

del sistema Electronic Medical File ”.

Anexo 2 – Formato para Reporte de Hallazgos

A continuación se presenta el formulario correspondiente al reporte de hallazgos del

sistema “Electronic Medical File”.

91

Anexo 3– Detalle de Pruebas a Realizar

A continuación se presenta la herramienta que permite el registro y control de los casos de

prueba diseñados para el Electronic Medical File” y que se utilizará en esta etapa de

mejoras.

92

Anexo 4 – Asignación del Equipo de trabajo

A continuación se presenta el formulario correspondiente a la asignación del equipo de

prueba para el sistema Electronic Medical File

Asignación del Equipo de Pruebas

Proyecto: Electronic Medical File

Rol Personas Asignadas

Coordinador del equipo de

prueba

Sr. Melvin Jiménez

Especialista técnico Sr.Melvin Jiménez

Especialista en Soporte

Técnico

Sra. Jenny Sandoval

Especialista del área

funcional

Sra. Marianyela Magallón

Analista de negocio Sra. Alejandra Flores

Desarrollador del

producto

Sra. Ariana Cerdas

Sra. Jenny Sandoval

Asesor metodológico Sra. Alejandra Flores

expediente médico electrónico

Documents