VRPVVG4 V 3

Sistema de registros – Diálisis Crónico
Plan de Verificación y Validación

Versión 3.0
Historia de revisiones
Fecha Versión Descripción Autor
22/08/2007 1.0 Responsable de verificación Karina Rapetti
23/08/2007 1.1 Revisión del documento Javier Lazo
09/09/2007 2.0 Revisión de documento Javier Lazo
20/10/2007 3.0 Ajuste del plan. ComentarioKarina Rapetti
respecto a las pruebas unitarias,
casos de usos verificados,
pruebas del sistema
Plan de Verificación y Validación Página 1 de 23

Contenido
1 INTRODUCCIÓN 4
1.1 PROPÓSITO 4
1.2 PUNTO DE PARTIDA 4
1.3 ALCANCE 5
1.4 IDENTIFICACIÓN DEL PROYECTO 6
1.5 ESTRATEGIA DE EVOLUCIÓN DEL PLAN 6
2 REQUERIMIENTOS PARA VERIFICAR 7
3 ESTRATEGIA DE VERIFICACIÓN 10
3.1 TIPOS DE PRUEBAS 11
3.1.1 Prueba de Funcionalidad 11
3.1.1.1 Objetivo de la prueba 11
3.1.1.2 Técnica 11
3.1.1.3 Criterio de aceptación 12
3.1.1.4 Consideraciones especiales 12
3.1.2 Prueba de Ciclo del Negocio 12
3.1.2.2 Técnica 12
3.1.3 Prueba de Interfaz de Usuario 12
3.1.3.2 Técnica 13
3.1.4 Prueba de Carga 13
3.1.4.2 Técnica 13
3.1.5 Prueba de Fallas y Recuperación 14
3.1.5.2 Técnica 14
3.2 HERRAMIENTAS 15
4 RECURSOS 16
4.1 ROLES 16
4.2 SISTEMA 17
5 HITOS DEL PROYECTO DE VERIFICACIÓN 18
6 ENTREGABLES 18
6.1 MODELO DE CASOS DE PRUEBA 18
6.2 INFORMES DE VERIFICACIÓN 19
6.3 EVALUACIÓN DE LA VERIFICACIÓN 20
6.4 INFORME FINAL DE VERIFICACIÓN 20
7 DEPENDENCIAS 21
7.1 DEPENDENCIA DE PERSONAL 21
7.2 DEPENDENCIA DE SOFTWARE 21
7.3 DEPENDENCIA DE HARDWARE 21
7.4 DEPENDENCIA DE DATOS Y BASE DE DATOS DE PRUEBA 21

8 RIESGOS 21
8.1 PLANIFICACIÓN 21
9 APÉNDICE 23
9.1 NIVELES DE GRAVEDAD DE ERROR 23
9.2 NIVELES DE ACEPTACIÓN PARA LO ELEMENTOS VERIFICADOS 23

1 Introducción
1.1 Propósito
Este Plan de Verificación para el proyecto Sistema de registros – Diálisis
Crónico soporta los siguientes objetivos:
 Identificar la información de proyecto existente y los componentes de
software que deben ser verificados.
 Enumerar los requerimientos recomendados para verificar.
 Recomendar y describir las estrategias de verificación que serán
usadas.
 Identificar los recursos necesarios y proporcionar una estimación de
esfuerzo para realizar la verificación.
 Enumerar los entregables del proyecto de verificación.
1.2 Punto de partida

La verificación tiene por objetivo descubrir defectos para corregirlos y evaluar
la calidad de los productos. A su vez asegura que el producto cumple con los
requerimientos funcionales y no funcionales que el cliente especificó, logrando
la satisfacción del mismo.
El destino de la verificación son todos los componentes desarrollados a lo
largo del proyecto así como también su interacción e integración.
El proyecto Sistema de registros – Diálisis Crónico tiene como fin lograr

comunicar el centro de diálisis crónica del Hospital Maciel (IMAE), con el
Fondo Nacional de Recurso (FNR).
En la actualidad todos los centros que realizan diálisis forman parte de una
IMAE. El FNR es quien brinda los recursos a las distinta IMAES en particular a
las que nos interesan en éste proyecto, para que los pacientes realicen sus
tratamientos.
Como se ve en la descripción de arriba, éste proyecto cuenta con dos clientes
y ambos con fines distintos. Lo que busca el FNR es definir un estándar para
Uruguay el cual defina un formato para comunicar la información clínica
relevante hacía el FNR. Siendo este pasaje lo mas seguro posible.
Del lado del Hospital Maciel, lo que se busca es tener un registro clínico de los
distintos pacientes que son dializados en su centro, en sus dos posibles
formas hemodiálisis o diálisis peritoneal. También están interesados en tener
un registro de los pacientes que se encuentran en Pre - diálisis.
Es importante hacer notar que en estos momentos las IMAES se comunican

con el FNR, a través de un sistema llamado Maria el cual fue desarrollado por
el fondo. Por lo que se pudo relevar el diseño de las interfaces es muy
precario y posee algunas funcionalidades que deberían ser actualizadas.
Otro punto interesante para mencionar es el prototipo que se obtuvo de la

instancia CONECTATON el cual ha sido puesto a nuestra disposición, su
descripción y su código.

1.3 Alcance
Las fases por la cual va ir cursando la verificación son las siguientes
 En una primera instancia se realizarán las pruebas unitarias, estas
pruebas serán realizadas por los implementadores en el ambiente de
desarrollo con apoyo de los verificadores, verificando el funcionamiento
del componente. Como salida de estas pruebas unitarias tendremos los
informes de verificación correspondientes los cuales registrarán los
errores encontrados y los que no fueron solucionados en la iteración.
La técnica aplicada para verificar será dinámica y de caja negra.
Usando Particiones de equivalencia y análisis de valores límites.
Los implementadores deberán priorizar los módulos más críticos y
verificar en mayor medida dichos módulos. Los casos de prueba
definidos deben ser cubiertos en su totalidad.
 También se realizarán pruebas de integración, el diseño de los casos

de prueba de la integración, serán construidos por los verificadores con
el apoyo de los implementadores ya que éstos poseen un conocimiento
detallado de las interfaces y funciones en general. El equipo de
verificación será el responsable de testear las interfaces gráficas.
La técnica aplicada para verificar la integración será incremental y
preferentemente de Bottom-Up esto permite no generar Stub que en
general su construcción consume demasiado tiempo. Lo que sí se
deberá generarse son Drivers, pero éstos últimos son menos costosos.
Estas pruebas se realizarán en la fase de construcción y transición. El
resultado de las pruebas deberá ser informado, reportando los errores
a los implementadores.
 Otro tipo de pruebas a realizar serán las pruebas funcionales, las

cuales serán responsabilidad del equipo de verificación, en las mismas
se constará del documento de requerimiento para verificar los
resultados obtenidos con los esperados. En ésta etapa se verifica la
funcionalidad del sistema. Para nuestro sistema lo haremos en base a
los casos de usos, identificando los distintos escenarios y usándose
éstos como base para las condiciones de prueba, una vez identificadas
las condiciones se crearán los casos de pruebas.
 Serán importantes realizar pruebas de regresión, éstas serán

realizadas por los verificadores, comprobando que ante un agregado o
cambio en las funcionalidades el resto de las funcionalidades ya
verificadas no se vean afectadas, y cumpla con la especificación de
requerimientos.
 Luego de haber probado el sistema funcionalmente se ejecutarán las

pruebas de desempeño. Estas pruebas buscan verificar los
requerimientos no funcionales que el cliente especificó en un ambiente
objetivo. Para éste punto debemos definir el procedimiento de
pruebas, el criterio de aceptación y las características del ambiente.
Dentro de las posibles pruebas de desempeño y ajustándonos a la
realidad creemos interesante priorizar pruebas de seguridad,
confiabilidad, facilidad de uso, rendimiento y pruebas de
documentación, entre otras.

 En la etapa posterior se validará con el cliente, realizando las pruebas
de aceptación y de instalación en el ambiente de trabajo. Validando el
funcionamiento correcto del sistema.
Un posible riesgo detectado para realizar las pruebas de integración es el no

tener bien definido el ambiente de trabajo.
Otro posible riesgo para realizar las pruebas, es el tiempo que hay entre que
el implementador termina y el período que se debe entregar el componente.
Este tiempo se va a planificar en el proyecto pero no deja de ser un riesgo
para el buen funcionamiento de la verificación.
1.4 Identificación del proyecto

Los documentos usados para elaborar el Plan de Verificación son los
siguientes:
 Transparencias de verificación y validación de la materia introducción a
la ingeniería de software
 Plantilla del Plan de Verificación y Validación especificada en el Modelo
de Proceso Modularizado Unificado y Medible (MUM) utilizado durante
este proyecto.
 Documento de Especificación de Requerimiento
 Plan de verificación y validación de otros años tomado de la Memoria
Organizacional de la asignatura.
1.5 Estrategia de evolución del Plan
Debe contener:
 El responsable de monitorear el Plan de Verificación y Validación es el
responsable de verificación, el responsable en las dos primeras fases deberá
planificar la verificación, evaluando y ajustando el plan.
 Las modificaciones al plan se realizarán en cada iteración. Podrán ser
propuestas por todo el equipo de verificadores, estos cambios serán
aprobados y evaluados por el responsable de verificación y los asistentes de
verificación.
 Los cambios del plan de verificación y validación serán informados al resto
del grupo por medio del responsable de verificación.

2 Requerimientos para verificar
En la lista a continuación se presentan los elementos, casos de uso,
requerimientos funcionales y requerimientos no funcionales, que serán
verificados.
2.1 Casos de Usos
Casos de usos que se van a implementar y verificar

 Alta de Formulario de Hemodiálisis
 Seleccionar Paciente Por Identificador
 Recepción del Formulario de Hemodiálisis
 Envío del formulario de Hemodiálisis
 Alta de Plan de Tratamiento
 Alta de Acceso Vascular
Casos de usos que quedan fuera del alcance del proyecto:

 Alta Paciente
 Baja de Paciente
 Modificación de Paciente
 Registro de Internación de Paciente
 Modificación de Acceso Vascular
 Modificación de Plan de Tratamiento
 Listado de Formularios Por Filtro
 Realizar Consulta
2.2 Requerimientos Funcionales detectados
 El usuario del sistema podrá dar de alta a un paciente. El sistema despliega

una pantalla donde se ingresan los datos demográficos del mismo, así como
también otros datos referentes al estado del paciente al momento de
comenzar a atenderse en el Maciel. El usuario confirma la acción. El sistema
verifica la correctitud de los datos, y que no exista ya un paciente en el
sistema con el mismo identificador (C.I.), si todo es correcto, da de alta el
paciente.
 El usuario del sistema podrá dar de baja a un paciente. Para ello se

selecciona un paciente del listado de pacientes disponibles, se ingresa el
motivo de la baja y confirma la acción. El sistema da de baja al paciente sin
eliminar los registros históricos del mismo.
 El usuario del sistema debe ser capaz de modificar los datos de un

determinado paciente. Para ello selecciona un paciente del listado de
pacientes disponibles y elige la opción modificar, se le presenta una pantalla
con los datos precargados del paciente, modifica los datos y confirma la
acción. El sistema verifica la correctitud de los mismos y en caso que estén
correctos guarda los cambios, en caso contrario retorna error y no modifica
los datos.

 El usuario del sistema puede dar de alta un plan de tratamiento, elige el
paciente al cuál asociará el plan. El sistema despliega una pantalla con los
datos del plan a ser llenados, estos incluyen información sobre la
alimentación y medicación indicadas al paciente, algunos de estos datos se
tendrán en cuenta en las sesiones de hemodiálisis que tenga el paciente
mientras dicho plan tenga vigencia. Luego de ingresados los mismos, el
usuario confirma la acción. El sistema chequea la correctitud de los mismos,
y da de alta el plan para el paciente seleccionado.
 El usuario del sistema puede modificar el plan de tratamiento de un

paciente, previamente debe seleccionar un paciente. Esta modificación
podría permitirse mientras el mismo no se haya puesto en práctica, o
durante la misma pero no luego de que la vigencia del mismo haya
caducado
 El usuario del sistema puede dar de alta a un acceso vascular de un

paciente, deberá seleccionar un paciente. Este formulario contiene la
información relevante del acceso vascular, tal como ubicación, tipo de
acceso, fecha de realizado, cirujano encargado de realizar la intervención y
las posibles complicaciones que haya podido tener.
 El usuario del sistema puede modificar los datos de un acceso vascular de un

paciente, previamente debe haber seleccionado un paciente.
 El usuario del sistema puede registrar la internación de un paciente en el

Maciel, previamente debe haber seleccionado un paciente. Los datos a
registrar son período de internación del paciente, la evolución del mismo y el
motivo de la internación, el cual puede deberse a complicaciones con algún
acceso vascular.
 El usuario del sistema puede registrar la sesión de Hemodiálisis para un

paciente, previamente debe de seleccionar la opción “Nuevo Formulario de
Hemodiálisis”. El sistema presenta la pantalla de ingreso del formulario en la
cual el usuario debe indicar el paciente al cual corresponde la sesión de
hemodiálisis en cuestión.
Para indicar el paciente lo podría hacer mediante el CU Seleccionar Paciente.
Luego de esto el sistema despliega en pantalla el formulario de hemodiálisis,
el cual viene pre-cargado, ya que algunos de los datos son inferidos de los
datos personales, plan de tratamiento, registro de accesos asociados al
paciente y que todavía están vigentes. De no haber alguno de estos en
vigencia se tomará la información del último registrado para este paciente.
El usuario ingresa los demás datos y modifica los desplegados si así lo
desea. Luego de esto selecciona la opción “Finalizar”. El sistema verifica que
los datos ingresados sean correctos, y que se encuentren todos los datos
requeridos. Luego de esto registra los datos en la base de datos del
componente Maciel y se invoca el CU Envío de Formulario de Hemodiálisis.
 El usuario luego que ha llenado todos los datos correspondientes a una

sesión de hemodiálisis (ver caso de uso Llenar Formulario de Hemodiálisis)
puede ser capaz de enviar el formulario al FNR. Para esto luego que el
usuario seleccionó la opción finalizar, el sistema genera a partir de los datos
ingresados un CDA, e invoca al servicio de recepción de datos del FNR, para
transmitirle dicho CDA.

El sistema espera la respuesta de dicho servicio, y si el mismo no retorna
error, da por finalizado el caso de uso. En caso contrario el sistema notifica
del error al usuario.
 El usuario del sistema puede ser capaz de seleccionar una paciente a través
de su identificador, para esto elige la opción Buscar Paciente, el sistema
presenta en pantalla los posibles datos por los cuales especificar la búsqueda
del paciente. Estos son cédula de identidad, Nombre, Apellido y Número de
registro en el FNR. El Usuario ingresa alguno o varios de estos. El sistema
despliega en pantalla la lista de pacientes registrados en el Maciel que
cumplen con las condiciones especificadas.
Si la opción fue invocada cuando se estaba dando de alta a un formulario de
hemodiálisis. Se brindará la opción de seleccionar un paciente de la lista
para proceder a llenar el formulario de hemodiálisis. Si fuera invocado
cuando se quiere enviar el formulario al FNR, se brindará la opción de
seleccionar un paciente de la lista para proceder a seleccionar el formulario
de hemodiálisis a enviar
 Un usuario del sistema, podrá seleccionar hacer consultas para esto se le

desplegara una lista con las consultas que puede realizar. El sistema le
retornara el resultado de la consulta seleccionada.
 El usuario del sistema, podrá listar los formularios aplicando filtros, para
esto ingresa en la pantalla de listado de formularios, especifica las
condiciones de búsqueda y selecciona la opción listar. El sistema despliega
en pantalla un listado con los formularios que cumplen con las condiciones
de búsqueda.
 Cuando el subsistema Maciel invoca al servicio de recepción de datos del

subsistema FNR, para la transmisión de datos. El subsistema Maciel realiza
la invocación pasándole al servicio un formulario de hemodiálisis. El FNR
chequea la correctitud del formato del mismo, y de los datos contenidos. En
caso que no haya errores, guarda dichos datos en su Base de Datos, en caso
contrario retorna una respuesta de error y deshecha los datos.
La recepción de estos formularios se realiza a través de un Web Service, el
cual es invocado por el subsistema del Hospital Maciel.
Se recibe una estructura que contiene los datos del formulario, la misma es
desglosada para identificar cada campo enviado, se valida y si todo está bien
se mapea la información con la base de datos del FNR persistiendo los
mismos.
Además de la estructura antes mencionada se recibe un parámetro que sirve
de autenticación, para asegurar que la invocación de este servicio ha sido
por una IMAE autorizada, por ejemplo el registro de una hemodiálisis por
parte del Hospital Maciel.

2.3 Requerimientos no funcionales detectados
 HL7 CDA: para transferencia de información clínica

 IHE: para perfil de transferencia de documentos clínicos.
 Seguridad
o En la transferencia de información
o Autorización para las transacciones
 Licencias
o Uso de herramientas bajo licencia GPL
 Servidor
o JBoss versión 4.2
3 Estrategia de Verificación
La verificación de los módulos, será realizada por los implementadores, ya
que estos son los que poseen el conocimiento detallado de los módulos a
implementar, tendrán la responsabilidad de diseñar los correspondientes
casos de prueba basándose en la especificación formal del módulo a
implementar. En el caso de clases muy críticas con previo aviso de los
implementadores los verificadores diseñarán casos de pruebas para testear
las mismas.
Para cada iteración el responsable de verificación debe entregar el

cronograma de las actividades de verificación de la iteración, para realizarlo
debe tener en cuenta el plan de integración de la iteración y la planificación
del coordinador de desarrollo.
El diseño de los casos de prueba será construido por los verificadores e

implementadores ya que estos son los que tienen más claro las
funcionalidades de los distintos módulos y su prioridad. El equipo de
verificación será el responsable de testear las interfaces gráficas.
El equipo de verificadores deberá realizar pruebas funcionales, de desempeño,

de aceptación y de instalación. Para dichas pruebas se generaran los casos de
prueba y sus respectivos reportes, los cuales deberán ser entregados al
responsable de verificación.
Por cada versión liberada se deberá seguir el siguiente ciclo, considerando que
la duración del ciclo corresponde a una iteración
 Configurar el ambiente de prueba
o Lo realiza el equipo de verificadores
o De ser necesario se solicita la participación de los
implementadores involucrados.
 Diseño de las pruebas
o Lo realiza el equipo de verificadores
o Se escriben los casos de prueba que se van a ejecutar.
 Ejecución de las pruebas
o Lo realiza el equipo de verificadores.

o Los resultados posibles son: “Aprobado”,”No Aprobado”,
“Aprobado con observaciones”. El valor esperado de la salida
está formalmente especificado en el documento de
requerimientos.
 Seguimiento de las pruebas
o Lo realiza el responsable de verificación.
o Se lleva registro de los distintos incidentes, reportando,
gerenciando y analizando los defectos encontrados en la
ejecución de las pruebas.
3.1 Tipos de pruebas

En las secciones a continuación, se incluyen las pruebas que se van ha
realizar al producto, validadas por el cliente Sebastián Scotti.
 Prueba Funcional
 Prueba de Ciclo del Negocio
 Prueba de Interfaz de Usuario
 Prueba de Fallas y Recuperación
 Prueba de Carga
3.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 interfase de usuario y analizar los resultados obtenidos.
3.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.
3.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.

3.1.1.3 Criterio de aceptación
Todas las pruebas planificadas se realizaron. Todos los defectos encontrados
han sido debidamente identificados.
3.1.1.4 Consideraciones especiales

Identificar o describir aquellos elementos o problemas (internos o externos)
que impactaron en la implementación y ejecución de las pruebas de
funcionalidad.
3.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.

Asegurar que la aplicación funciona de acuerdo a los requerimientos del
negocio.
3.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.

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

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.
3.1.3 Prueba de Interfaz de Usuario

Esta prueba verifica que la interfase 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 interfase de usuario se muestren como se
espera y conforme a los estándares establecidos por la empresa o de la
industria.
En éste punto se resaltó que se quiere testear que los datos que el sistema
precarga del plan de tratamiento sean identificados en la interfaz.

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, estado funcionen de acuerdo
a los estándares.
3.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.

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

No todas las propiedades de los objetos se pueden acceder.
3.1.4 Prueba de Carga

La prueba de carga somete los objetos a verificar a diferentes cargas de
trabajo para medir y evaluar los comportamientos de performance y la
habilidad de los objetos de continuar funcionando apropiadamente bajo
diferentes cargas de trabajo. El objetivo es determinar y asegurar que el
sistema funciona apropiadamente en circunstancias de máxima carga de
trabajo esperada. Además evaluar las características de performance, como
tiempos de respuesta, tiempos de transacciones y otros elementos sensitivos
al tiempo.
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.

Verificar el comportamiento de performance de determinados componentes
del software bajo condiciones de trabajo diferentes.
3.1.4.2 Técnica
Usar pruebas desarrolladas para funciones o ciclos de negocios y modificar
archivos de datos para aumentar el número de transacciones o las pruebas
para aumentar la cantidad de ocurrencia de transacciones.

Para múltiples transacciones y múltiples usuarios: Realización exitosa de las
pruebas sin fallas y dentro del tiempo aceptable.

La prueba de carga debe realizarse en una máquina dedicada para tener
control total y exactitud de mediciones.
Las bases de datos usadas para la prueba deben tener un tamaño similar a las
reales.
3.1.5 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.

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.
3.1.5.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

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.

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.
3.2 Herramientas
Para especificar los casos de prueba se utilizará Excel, Se hizo una plantilla
Excel para los casos de pruebas unitarias la cual será completada por lo
implementadores, su nombre es PruebaUnitaria.xls y a su vez se hizo una
plantilla de prueba para los casos de usos, ésta será completada por los
verificadores, su nombre es PruebaCasosUso.xls.
La vista de la planilla de PruebaUnitaria.xls es la siguiente:

La vista de la planilla de PruebaCasoUso.xls es la siguiente:
Para el registro de incidentes se usará Word.
4 Recursos
En esta sección se presentan los recursos recomendados para el proyecto
Sistemas de registros – Diálisis crónico, sus principales responsabilidades y su
conocimiento o habilidades.
4.1 Roles
En la tabla a continuación se muestra la composición de personal para el
proyecto Sistemas de registros – Diálisis crónico en el área Verificación del
Software.
Rol Cantidad mínima Responsabilidades
de recursos
recomendada
Responsable de 1 Identifica, prioriza e implementa
verificación los casos de prueba.
 Genera el Plan de
Verificación.
 Genera el Modelo de
Prueba.
 Evalúa el esfuerzo
necesario para verificar.
 Proporciona la dirección
técnica.
 Adquiere los recursos
apropiados.
 Proporciona informes
sobre la verificación.

Asistente de 4  Ejecuta las pruebas
verificación  Registra los resultados de
las pruebas.
 Recupera el software de
errores.
 Documenta los pedidos
de cambio.
4.2 Sistema
En la siguiente tabla se establecen los recursos de sistema necesarios para
realizar la verificación.
Es recomendable que el sistema simule el entorno de producción, reduciendo
los accesos y los tamaños de bases de datos si fuera apropiado.
Recurso Nombre/Tipo
Red o subred LAN o local
Nombre del servidor No está definido
Nombre de la base de datos No está definido
PC Cliente para pruebas No esta definido
Requerimientos especiales Se tiene que tener instalado un servidor
JBoss 4.2, con Manejador de base de
datos Oracle 9i, java versión 1.5
Repositorio de pruebas Se usara Mantis, como repositorio de
pruebas

5 Hitos del proyecto de Verificación
La verificación del Sistemas de registros – Diálisis crónico debe incorporar
actividades de prueba para cada verificación identificada en las secciones
anteriores. Se deben identificar los hitos del proyecto de verificación
separados para comunicar los logros de estado de proyecto.
Actividad que determina Esfuerzo Fecha de Fecha de

el hito comienzo finalización
Planificar la verificación 11hs/semana 20/08/2007 10/09/2007
Semana 1 Semana 4
Elaborar casos de prueba 20hs/semana 20/08/2007 05/11/2007
(semanas pares) Semana 1 Semana 12
Ajuste y Control de 7hs/semana Fase Inicial 15/10/2007
Verificación iteración 1 Semana 9
10/09/2007
Semana 4
29/10/2007
Fase de Semana 11
Construcción
iteración 2
15/10/2007
Semana 9
Ejecutar la verificación 30hs/semana Semana 7 Semana 13
(Semana impar) 27/9/2007 12/11/2007
Evaluar la verificación 15hs/semana Semana 5 Semana 13

(Semana impar) 10/09/2007 12/11/2007
6 Entregables
En esta sección enumere los documentos, herramientas e informes que se
crearán, por quien, para quien y cuándo serán liberados.
Para cada entregable deberá indicar las fechas en que son liberadas todas las
versiones del mismo.
6.1 Modelo de Casos de Prueba

Documento Modelo de Casos de Prueba
Creado por El Responsable de verificación, Karina Rapetti
Para quien Es la guía para realizar las pruebas del sistema y lo usarán
los Asistentes de verificación y el Responsable de
verificación cuando se ejecuten las pruebas del sistema.
Fecha de liberación  Entrega de la Semana 4 27/08/2007 (Prototipo)
 Entrega de la Semana 5 17/09/2007

6.2 Informes de Verificación

Documento Se genera un documento Informe de Verificación por
cada verificación que hacen los verificadores
Creado por Las personas que ejecutan las pruebas. Implementadores
Para quien Es el retorno para los implementadores de la tarea de
verificación, que detalla los errores encontrados para que
puedan ser corregidos.
Fecha de liberación Será liberado luego de cada verificación unitaria.
 Entrega de la semana 5, 10/09/2007 (Prototipo)
 Entrega de la semana 6, 17/09/2007
Documento Se genera un documento Informe Consolidación

por cada consolidación que se realice al sistema.
Creado por Las personas que ejecutan las pruebas.
consolidación, que detalla los errores encontrados
para que puedan ser corregidos.
Fecha de liberación Será liberado luego de cada consolidación.
No se ha definido fecha aún
Documento Se genera un documento Informe de Verificación

de Integración por cada prueba de integración que
se realice al sistema.
Creado por Las personas que ejecutan las pruebas.
verificación, que detalla los errores encontrados para
que puedan ser corregidos.
Fecha de liberación Será liberado luego de cada verificación de
integración.

Documento Se genera un documento Informe de Verificación
de Sistema por cada prueba de sistema que se
realice.
Creado por Las personas que ejecutan las pruebas
verificación, que detalla los errores encontrados para
que puedan ser corregidos.
Fecha de liberación Será liberado luego de cada verificación de sistema.
6.3 Evaluación de la verificación

Documento Se genera un documento Evaluación de la
verificación por cada prueba que se realice al
sistema. Este documento contiene las fallas
encontradas en el sistema, la cobertura de la
verificación realizada y el estado del sistema.
Creado por El Responsable de verificación, que toma como fuente
de su trabajo los Informes de verificación.
Para quien Es el resumen de la tarea de verificación y es el
retorno para todo el equipo de trabajo del estado del
sistema.
Fecha de liberación Será liberado luego de cada verificación, unitaria, de
integración y de sistema.
6.4 Informe final de verificación

Documento El documento Informe final de verificación es el
resumen de la verificación final del sistema antes de
que sea liberado al entorno del usuario.
Creado por El Responsable de verificación, que toma como fuente
de su trabajo los Informes de verificación.
Para quien Indica el estado del sistema.
Fecha de liberación Será liberado luego de la verificación final del
sistema.
 Entrega de la semana 14 19/11/2007

7 Dependencias
7.1 Dependencia de personal

El equipo cuenta con cuatro asistentes de Verificación, si bien estas personas
tienen asignados otros roles que van a afectar su disponibilidad, deberán
trabajar con el responsable de Verificación en momentos de realizar la
verificación de la integración y las pruebas de sistema.
7.2 Dependencia de software

El software a ser verificado debe tener una verificación previa como se
describió anteriormente en el cual, los implementadores de los módulos hayan
realizado las pruebas unitarias y entregado los informes correspondientes.
7.3 Dependencia de hardware

No se han definido por el momento.
7.4 Dependencia de datos y base de datos de prueba

Ya mas avanzado el proyecto deberá definir la manera en la cual se realizarán
las pruebas en lo que respecta a la interacción con bases de datos ya
existentes en el Fondo Nacional de Recursos (FNR).
8 Riesgos
8.1 Planificación
Un riesgo que se deberá tener en cuenta es que la demora de las entregas de
algunos documentos hace que la verificación se vea entorpecida

9 Apéndice
9.1 Niveles de gravedad de error

Van a existir cuatro niveles diferentes de gravedad de error que se pueden
asignar a las actividades del proceso de verificación:
 Catastrófico: un error cuya presencia impide el uso del sistema.

 Crítico: un error cuya presencia causa la pérdida de una funcionalidad
crítica del sistema. Si no se corrige el sistema no satisfará las
necesidades del cliente.
 Marginal: un error que causa un daño menor, produciendo pérdida de
efectividad, pérdida de disponibilidad o degradación de una
funcionalidad que no se realiza fácilmente de otra manera.
 Menor: un error que no causa perjuicio al sistema, pero que requiere
mantenimiento o reparación. No causa pérdida de funcionalidades que
no se puedan realizar de otra manera.
9.2 Niveles de aceptación para lo elementos verificados

En esta sección defina niveles de aceptación y los criterios de pertenencia a
cada nivel para los documentos que los asistentes y el responsable de
verificación pueden asignar.
 No aprobado: el elemento verificado tiene errores catastróficos (uno

o varios) que impiden su uso o tiene errores críticos (uno o varios) que
hacen que el elemento verificado no sea confiable. El usuario no puede
depender de él para realizar el trabajo.
 Aprobado con Observaciones: el elemento verificado no tiene
errores catastróficos, ni errores críticos, pero tiene errores marginales
(uno o varios) que hacen que el elemento de software se degrade en
algunas situaciones.
 Aprobado: el elemento verificado no tiene errores o tiene errores
menores que no afectan el normal funcionamiento del elemento.]

VRPVVG4 V 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

VRPVVG4 V 3

Cargado por

Copyright:

Formatos disponibles

Sistema de registros – Diálisis Crónico

Plan de Verificación y Validación

Plan de Verificación y Validación Página 1 de 23

Plan de Verificación y Validación Página 2 de 23

Plan de Verificación y Validación Página 3 de 23

1.2 Punto de partida

El proyecto Sistema de registros – Diálisis Crónico tiene como fin lograr

Es importante hacer notar que en estos momentos las IMAES se comunican

Otro punto interesante para mencionar es el prototipo que se obtuvo de la

Plan de Verificación y Validación Página 4 de 23

 También se realizarán pruebas de integración, el diseño de los casos

 Otro tipo de pruebas a realizar serán las pruebas funcionales, las

 Serán importantes realizar pruebas de regresión, éstas serán

 Luego de haber probado el sistema funcionalmente se ejecutarán las

Plan de Verificación y Validación Página 5 de 23

Un posible riesgo detectado para realizar las pruebas de integración es el no

1.4 Identificación del proyecto

1.5 Estrategia de evolución del Plan

Plan de Verificación y Validación Página 6 de 23

2.1 Casos de Usos

Casos de usos que se van a implementar y verificar

Casos de usos que quedan fuera del alcance del proyecto:

2.2 Requerimientos Funcionales detectados

 El usuario del sistema podrá dar de alta a un paciente. El sistema despliega

 El usuario del sistema podrá dar de baja a un paciente. Para ello se

 El usuario del sistema debe ser capaz de modificar los datos de un

Plan de Verificación y Validación Página 7 de 23

 El usuario del sistema puede modificar el plan de tratamiento de un

 El usuario del sistema puede dar de alta a un acceso vascular de un

 El usuario del sistema puede modificar los datos de un acceso vascular de un

 El usuario del sistema puede registrar la internación de un paciente en el

 El usuario del sistema puede registrar la sesión de Hemodiálisis para un

 El usuario luego que ha llenado todos los datos correspondientes a una

Plan de Verificación y Validación Página 8 de 23

 Un usuario del sistema, podrá seleccionar hacer consultas para esto se le

 Cuando el subsistema Maciel invoca al servicio de recepción de datos del

Plan de Verificación y Validación Página 9 de 23

 HL7 CDA: para transferencia de información clínica

Para cada iteración el responsable de verificación debe entregar el

El diseño de los casos de prueba será construido por los verificadores e

El equipo de verificadores deberá realizar pruebas funcionales, de desempeño,

Plan de Verificación y Validación Página 10 de 23

3.1 Tipos de pruebas

3.1.1 Prueba de Funcionalidad

3.1.1.1 Objetivo de la prueba

Plan de Verificación y Validación Página 11 de 23

3.1.1.4 Consideraciones especiales

3.1.2 Prueba de Ciclo del Negocio

3.1.2.1 Objetivo de la prueba

3.1.2.3 Criterio de aceptación

3.1.2.4 Consideraciones especiales

3.1.3 Prueba de Interfaz de Usuario

Plan de Verificación y Validación Página 12 de 23

3.1.3.3 Criterio de aceptación

3.1.3.4 Consideraciones especiales

3.1.4 Prueba de Carga

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

3.1.4.1 Objetivo de la prueba

3.1.4.3 Criterio de aceptación

Plan de Verificación y Validación Página 13 de 23

3.1.5 Prueba de Fallas y Recuperación

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

3.1.5.1 Objetivo de la prueba