Sistema de registros – Diálisis Crónico

Acta de Reunión de Requerimientos

Versión 1.0

Historia de revisiones
Fecha Versión Descripción Autor
12/10/2007 1.0 Reunión en el Hospital Maciel Javier Lazo y Karina
para definir características de la Rapetti.
calidad del producto.

Fecha: Viernes 12 de Octubre del 2007

Responsables: Sebastián Scotti.
Participantes: Javier Lazo y Karina Rapetti.

Reunión de Requerimientos Página 1 de 8

 ÍNDICE

TEMAS TRATADOS...................................................................................................................................3
1 VALIDACIÓN DE ALGUNAS CARACTERÍSTICAS DE CALIDAD..............................................................4
1.1 Seguridad...................................................................................................................................4
1.2 Mantenibilidad y modificaciones futuras..................................................................................4
1.3 Satisfacción con productos liberados o con el avance del sistema...........................................4
1.4 Funcionalidades y adecuación..................................................................................................4
1.5 Portabilidad y facilidad de instalación del producto................................................................4
2 DEFINIR PRUEBAS DEL SISTEMAS.......................................................................................................5
2.1 Revisión y validación de Datos del Documento Modelo de Dominio.......................................5
2.1.1 Prueba de Funcionalidad...........................................................................................................5
2.1.1.1 Objetivo de la prueba.....................................................................................................5
2.1.1.2 Técnica...........................................................................................................................5
2.1.1.3 Criterio de aceptación....................................................................................................5
2.1.2 Prueba de Ciclo del Negocio....................................................................................................5
2.1.2.1 Objetivo de la prueba.....................................................................................................6
2.1.2.2 Técnica...........................................................................................................................6
2.1.2.3 Criterio de aceptación....................................................................................................6
2.1.2.4 Consideraciones especiales............................................................................................6
2.1.3 Prueba de Interfaz de Usuario...................................................................................................6
2.1.3.1 Objetivo de la prueba.....................................................................................................6
2.1.3.2 Técnica...........................................................................................................................6
2.1.3.3 Criterio de aceptación....................................................................................................6
2.1.3.4 Consideraciones especiales............................................................................................6
2.1.4 Prueba de Fallas y Recuperación..............................................................................................7
2.1.4.1 Objetivo de la prueba.....................................................................................................7
2.1.4.2 Técnica...........................................................................................................................7
2.1.4.3 Criterio de aceptación....................................................................................................7
2.1.4.4 Consideraciones especiales............................................................................................7
3 Posible inclusión de la herramienta testNg........................................................................................8

Reunión de Requerimientos Página 2 de 8

Temas Tratados
Se le preguntó al cliente sobre algunas características de la calidad del producto.
Entre estas se encontraban la seguridad, usabilidad y funcionalidades más
prioritarias.
También se definió con el cliente las pruebas del sistema que le interesa que se
realicen.
Y por último se tomó conocimiento de la herramienta testNg como un
requerimiento más del cliente para realizar y registrar las pruebas del sistema. Esta
herramienta fue mostrada mediante un prototipo que el cliente Sebastián Scotti
tenía desarrollado.

1 Validación de algunas características de Calidad

2 Definir pruebas del sistema que se realizarán al producto

3 Presentación de un prototipo por parte del cliente, el cual

utiliza la herramienta de testeo TestNG

Reunión de Requerimientos Página 3 de 8

1 Validación de algunas características de Calidad
Se le preguntó al cliente sobre algunas características de calidad. Estas preguntas
tienen como fin establecer el estado de la calidad del producto de acuerdo a lo
hecho y lo que resta por hacer.
Las características indagadas fueron:

 Seguridad
 Mantenibilidad y modificaciones futuras
 Satisfacción con productos liberados o con el avance del sistema
 Funcionalidades y adecuación
 Portabilidad y facilidad de instalación del producto

1.1 Seguridad
Sobre este punto el cliente fue contundente mostrando un claro margen de
negociación. De todos los requerimientos que se solicitaron para el sistema, esté es
el que considera de menor prioridad. Se define entonces que en términos de la
calidad del producto ésta característica no es prioritaria.

1.2 Mantenibilidad y modificaciones futuras

Ésta característica se define en base a la evaluación de la herramienta testng que el
cliente planteó utilizar. La razón que se nos dio para la utilización de testng es que
si en el futuro se le agregan nuevos componentes o si se modifica alguno ya
existente, se puedan hacer pruebas de regresión para verificar que se sigue
cumpliendo con las funcionalidades que se definieron para el producto entregado.

1.3 Satisfacción con productos liberados o con el avance del sistema

En este punto el cliente explicó que el prototipo pronto a liberar le parece
demasiado grande y que se podría haber dividido en prototipos más pequeños. Por
otro lado dijo estar más tranquilo sabiendo que se había utilizado la librería javasig
que él había recomendado.
También definió lo que para él es un producto aceptable. Éste debería contener los
casos de uso más importantes del lado del hospital Maciel (ver documento de
alcance), la comunicación con el FNR y la validación del CDA recibido del lado del
FNR.

1.4 Funcionalidades y adecuación

El cliente hizo referencia a los casos de uso más importantes como son los de Alta
Plan de tratamiento, Alta de acceso vascular, Alta internación y los casos de uso
con menos prioridad como Alta paciente y Modificación de paciente.

1.5 Portabilidad y facilidad de instalación del producto

Ésta característica fue claramente definida por el cliente quedando establecido que
la entrega del producto se realizará mediante un archivo de tipo EAR de los fuentes
de la aplicación.

Reunión de Requerimientos Página 4 de 8

2 Definir pruebas del sistemas
Se definieron las pruebas del sistema que el cliente desea que se realicen.
Estas pruebas quedaron definidas de ésta manera:

2.1 Revisión y validación de Datos del Documento Modelo de Dominio

Respecto a éste punto se decidió realizar las siguientes pruebas al producto:

 Prueba Funcional
 Prueba de Ciclo del Negocio
 Prueba de Interfaz de Usuario
 Prueba de Fallas y Recuperación

2.1.1 Prueba de Funcionalidad

La prueba de funcionalidad se enfoca en requerimientos para verificar que se
corresponden directamente a casos de usos o funciones y reglas del negocio.
Los objetivos de estas pruebas son verificar la aceptación de los datos, el
proceso, la recuperación y la implementación correcta de las reglas del
negocio. Este tipo de prueba se basa en técnicas de caja negra, que consisten
en verificar la aplicación y sus procesos interactuando con la aplicación por
medio de la interfaz de usuario y analizar los resultados obtenidos.

2.1.1.1 Objetivo de la prueba

Asegurar la funcionalidad apropiada del objeto de prueba, incluyendo la
navegación, entrada de datos, proceso y recuperación.

2.1.1.2 Técnica
Ejecute cada caso de uso, flujo de caso de uso, o función usando datos
válidos y no válidos, para verificar lo siguiente:
 Se obtienen los resultados esperados cuando se usan datos válidos.
 Cuando se usan datos no válidos se despliegan los mensajes de error
o advertencia apropiados.
 Se aplica apropiadamente cada regla del negocio.

2.1.1.3 Criterio de aceptación

Todas las pruebas planificadas se realizaron. Todos los defectos encontrados
han sido debidamente identificados.

2.1.2 Prueba de Ciclo del Negocio

Esta prueba debe simular las actividades realizadas en el proyecto en el
tiempo. Se debe identificar un período, que puede ser un año, y se deben
ejecutar las transacciones y actividades que ocurrirían en el período de un
año. Esto incluye todos los ciclos diarios, semanales y mensuales y eventos
que son sensibles a la fecha.

En éste punto se resaltó que se quiere testear bien la aplicación respecto a la

concurrencia de usuarios usando el producto, y haciendo cada uno una
funcionalidad distinta respecto de los otros.

Reunión de Requerimientos Página 5 de 8

2.1.2.1 Objetivo de la prueba
Asegurar que la aplicación funciona de acuerdo a los requerimientos del
negocio.

2.1.2.2 Técnica
La prueba debe simular ciclos de negocios realizando lo siguiente:
Las pruebas de funcionalidad se deben modificar para aumentar la cantidad
de veces que se ejecuta cada función, simulando varios usuarios diferentes en
un período determinado.
Todas las funciones sensibles a la fecha se deben ejecutar con fechas válidas
y no válidas o períodos de tiempos válidos y no válidos.
Para cada prueba realizada verificar lo siguiente:
 Se obtienen los resultados esperados cuando se usan datos válidos.
 Cuando se usan datos no válidos se despliegan los mensajes de error
o advertencia apropiados.
 Se aplica apropiadamente cada regla del negocio.

2.1.2.3 Criterio de aceptación

Todas las pruebas planificadas se realizaron. Todos los defectos encontrados
han sido debidamente identificados.

2.1.2.4 Consideraciones especiales

Las fechas del sistema y eventos requieren actividades de soporte especiales.
Se requieren las reglas del negocio para identificar apropiadamente los
requerimientos y procedimientos a ser verificados.

2.1.3 Prueba de Interfaz de Usuario

Esta prueba verifica que la interfaz de usuario proporcione al usuario el
acceso y navegación a través de las funciones apropiada. Además asegura
que los objetos presentes en la interfaz de usuario se muestren como se
espera y conforme a los estándares establecidos por la empresa o de la
industria.

2.1.3.1 Objetivo de la prueba

Verificar que la navegación a través de los elementos que se están probando
reflejen las funciones del negocio y los requerimientos, incluyendo manejo de
ventanas, campos y métodos de acceso; los objetos de las ventanas y
características, como menús, tamaño, posición y estado funcionen de acuerdo
a los estándares.

2.1.3.2 Técnica
Crear o modificar pruebas para cada ventana verificando la navegación y los
estados de los objetos para cada ventana de la aplicación y cada objeto
dentro de la ventana.

2.1.3.3 Criterio de aceptación

Cada ventana ha sido verificada exitosamente siendo consistente con una
versión de referencia o estándar establecido.

2.1.3.4 Consideraciones especiales

No todas las propiedades de los objetos se pueden acceder.

Reunión de Requerimientos Página 6 de 8

2.1.4 Prueba de Fallas y Recuperación
Las Pruebas de Fallas y Recuperación aseguran que el software puede
recuperarse de fallas de hardware, software o mal funcionamiento de la red
sin pérdida de datos o de integridad de los datos.
La Prueba de Recuperación es un proceso en el cual la aplicación o sistema se
expone a condiciones extremas, o condiciones simuladas, para causar falla,
como fallas en dispositivos de Entrada/Salida o punteros a la base de datos
inválidos. Los procedimientos de recuperación se invocan y la aplicación o
sistema es monitoreado e inspeccionado para verificar que se recupera
apropiadamente la aplicación o sistema y se logre la recuperación de datos.

En éste punto se resaltó que si el Maciel pierde conexión con el FNR y un

usuario envía el formulario de hemodiálisis, el formulario no debería de ser
enviado y el sistema debería de avisar que no es posible la conexión y lo
almacenaría en su base de datos.

2.1.4.1 Objetivo de la prueba

Verificar que los procesos de recuperación (manual o automáticos) recuperen
apropiadamente la base de datos, aplicaciones y sistema a un estado
conocido y deseado. En la prueba se incluyen los siguientes tipos de
condiciones:
 interrupción de comunicaciones mediante los servidores de la red

2.1.4.2 Técnica
Se deben usar las pruebas creadas para probar Funcionalidad y Ciclos de
negocio para crear una serie de operaciones. Una vez logrado el punto de
comienzo deseado, se deben realizar o simular las siguientes acciones,
individualmente:
 Interrupción por medio de los servidores de red: simular o iniciar la
pérdida de comunicación con la red (desconectar físicamente la
comunicación o apagar el servidor de red o router

2.1.4.3 Criterio de aceptación

En todos los casos, la aplicación, la base de datos y el sistema deben, en la
realización procedimientos de recuperación, volver a un estado conocido y
deseable. Este estado incluye corrupción de datos limitada al los campos,
punteros o claves corruptos conocidos, y reportes indicando los procesos u
operaciones que no se completaron debido a las interrupciones.

2.1.4.4 Consideraciones especiales

Los procedimientos para desconectar cables (simulando falta de energía o
pérdida de comunicación) no son deseables o factibles. Se pueden requerir
métodos alternativos, como software de diagnóstico. Se requieren los grupos
de recursos de Sistemas, Bases de datos y Red.
Estas pruebas deben ejecutarse fuera del horario de trabajo normal o en una
máquina aislada.

Reunión de Requerimientos Página 7 de 8

3 Posible inclusión de la herramienta testNg
El cliente nos mostró un prototipo utilizando la herramienta testng para realizar
pruebas unitarias o del sistema sobre el producto.
Se nos presentó un mini prototipo, el cual tiene ejemplo de clases testeadas. Y se
nos mostró como adaptar nuestro proyecto a la herramienta.
Para esto:

1- Se debe bajar el plugins org.teting.eclipse.5.6.0.0

2- Modificar el ClassPath agregando los jars correspondientes
3- Existe una carpeta que contiene las clases de prueba, para crear una
nueva prueba debo crear una clase.
4- Agregar a un xml llamado “testing” las distintas funcionalidades que se
quiera testear.
5- Para correr la prueba se hace con run sobre dicho xml.

Respecto a ésta herramienta, no se va a usar para el prototipo de la arquitectura.

Al cliente le interesa que queden las pruebas para que en un futuro se puedan
realizar pruebas de regresión.
El grupo de verificadores va evaluar la implantación y la curva de aprendizaje de
dicha herramienta.

Reunión de Requerimientos Página 8 de 8