Carrusel Integration

1
INTEGRACIÓN
Profesor: Guillermo Pinto Fuentes
INS7501-002V
Integrantes:
David Díaz.
David Fuentealba.
Carlos Jeldes.
Rodrigo Poblete.
Índice
Integración ERP – SGA Carrusel.

2
Introducción. 5
Requisitos del negocio 5
Objetivos de negocio y criterios de éxito 8
Minutas(Pendiente) 10
Descripción de situación actual 10
Descripción de la problemática presentada 10
Visión de la solución propuesta 10
Descripción de la solución propuesta 11
Características principales de la solución 11
Objetivos principales de la solución 11
Objetivos secundarios de la solución 12
Alcance del Proyecto 12
Limitaciones y exclusiones 12
Diseño lógico 13
Requisitos funcionales y no funcionales de integración. 13
Descripción de los actores del sistema. 13
Diagrama casos de Uso. 14
Descripción del patrón de arquitectura de integración 21
Diagrama de despliegue y componentes 27
27
BPMN del negocio actual 28
BPMN del negocio con las mejoras del sistema 29
Plan de pruebas 30
Casos de Prueba. 43
1.- Quiebre de Stock 43
2.- Actualización de Stock 45
3.- Verificación de Stock 46
4.- Reposición de medicamento 48
5.- Generación de reportes y licencias 49
6.- Validación de stock mínimo 51
7.- Validación de stock no negativo 52
8.- Validación de RUT 53
Diseño físico 58

3
Login 59
Perfil Administrador 59
Perfil Administrador (Menú Productos) 59
Perfil Administrador (Menú Usuarios) 60
Perfil Usuario 60
Perfil Usuario (Menú Productos) 60
Funciones 60
Función Agregar Producto 60
Función Traspasar Productos de Bodega a Farmacia 61
Función Lista Producto 61
Función Entrega de Producto 62
Función Agregar Producto 62
Función Lista de Usuarios 62
Función Mantenedor de Usuarios 63
Web Service Personal 63
Web Service Externo 65
Web Service Java 66
Conclusión. 68
Anexos (Minutas PENDIENTE MAS ARRIBA TAMBIEN) 68
Bibliografía 68

4
Introducción.
En la actualidad, las instituciones de salud del ámbito público deben actualizarse y
mejorar día a día para entregar un mejor servicio a sus pacientes (clientes). En el
área de la salud pública, el tiempo de espera para los pacientes ha sido siempre
un problema para los administradores, ya que es lo que el paciente siempre busca
reducir, es por esto que, aprovechando los recursos disponibles en la institución,
es necesario optimizarlos de la mejor manera posible para entregar un mejor
servicio.
Entregar a los beneficiarios del sistema de atención pública los medicamentos
recetados por los especialistas, con un alto nivel de compromiso, y respondiendo a
las necesidades médicas en cada etapa de la enfermedad, aportando
efectivamente a su salud y bienestar. Todo lo anterior basándose en sólidos
principios y valores ministeriales, como también en la ética médica que es siempre
un factor imprescindible para brindar un servicio de calidad y confiabilidad.

5
Requisitos del negocio

Existe una bodega dentro del Centro de Referencia de Salud que funciona
con un sistema ERP que controla el abastecimiento de todas las unidades
de la institución (clínicas, administrativas, etc.).
El sistema registra los movimientos, desde la adquisición de medicamentos
hasta que los mismos llegan a la bodega de la farmacia donde se entregan
a los usuarios. De este punto en adelante, el proceso se realiza de forma
manual. Se escriben en un cuaderno las entregas, y luego se digita lo
registrado en un módulo habilitado para este cometido en el ERP.
La entrega de productos a los pacientes y la administración dentro de la
bodega de los mismos no queda registrada en el ERP automáticamente. No
se ha integrado el sistema hasta este punto en la cadena de procesos, sino
que se lleva a cabo a través de un procedimiento manual, un empleado de
la farmacia se dedica a registrar en el cuaderno de movimientos todas las
entregas que se le realizan a los pacientes u otros usuarios que los
requieran, para posteriormente digitarlos en el módulo ERP, incluyendo la
fecha, el medicamento, el paciente, el médico que receta, etc. Esto provoca
lentitud administrativa en cuanto se le dedica un tiempo considerable al
registro y la digitación y demora en la gestión de los medicamentos al no
ser este proceso incorporado en el ERP, además, esto hace imposible llevar
un control en línea del stock realmente disponible para poder entregar los
productos prescritos por el médico en las recetas y realizar los pedidos a
adquisiciones con antelación.
Otro inconveniente es que los medicamentos que se encuentran en la
bodega de la farmacia no poseen un sistema de ubicaciones cartesianas
para la búsqueda factible de los medicamentos, sino que se depende de la
memoria y disponibilidad de quienes actualmente llevan el control de
existencias, para ello se están cotizando un almacenaje automatizado de
estantería carrusel.
En bodega central, es necesario agilizar las compras para el abastecimiento
de las farmacias, manejar un stock crítico y hacerlo visible para los distintos
usuarios del ERP, mejorar el despacho a los usuarios, disminuir los tiempos
de espera, automatizar la cadena de procesos y liberar horas-hombre
administrativas.
El médico debiera conocer en línea si el medicamento recetado tiene stock
o si la institución aún lo distribuye, para buscar un producto genérico
equivalente o bioequivalente, esto mediante la implementación de un

6
módulo de receta electrónica y registro clínico del paciente. A la vez, se

deberían registrar los medicamentos anteriormente recetados y los
tratamientos vigentes y/o anulados por otro profesional.
El usuario no debiera nunca tener la necesidad de realizar la compra del
medicamento en las cadenas de farmacias porque ello encarece sus costos
y va en contra la misión y visión de nuestro servicio e institución.
Visión
Como organismo de administración de medicamentos del Centro de
Referencia de Salud, los esfuerzos de la organización se orientan a estar
siempre a la vanguardia de la industria entregando un servicio rápido y
cómodo a los usuarios. A partir de esa premisa, el objetivo es cumplir con
las exigencias de una sociedad que avanza hacia una vida más saludable,
creando valor a largo plazo para nuestros usuarios, colaboradores y la
sociedad donde operamos.
Misión
Entregar a los beneficiarios del sistema de atención pública los
medicamentos recetados por los especialistas, con un alto nivel de
compromiso, y respondiendo a las necesidades médicas en cada etapa de
la enfermedad, aportando efectivamente a su salud y bienestar. Todo lo
anterior basándose en sólidos principios y valores ministeriales.

7
Organigrama institucional
Objetivos de negocio y criterios de éxito

Generar una integración que permita modelar el proceso de control de
medicamentos de la bodega de la farmacia de forma automática con el ERP que
gestiona el resto de las bodegas y con el software del carrusel dispensador de
medicamentos. Además conectar la información con el módulo de receta para
reemplazar el papel que incluye un registro clínico de los pacientes.
Criterios de éxito:
1. ERP integrado
2. Carrusel Dispensador integrado
3. Sistema funcionando con personal capacitado
Clientes
El Departamento de Promoción de Salud y Participación Ciudadana,

perteneciente a la División de Políticas Públicas Saludables y Promoción de
Salud, de la Subsecretaría de Salud Pública del Ministerio de Salud de Chile.

8
Como organismo de administración de medicamentos, los esfuerzos de la

organización se orientan a estar siempre a la vanguardia de la industria
entregando un servicio rápido y cómodo a los usuarios. A partir de esa premisa, el
objetivo es cumplir con las exigencias de una sociedad que avanza hacia una vida
más saludable, creando valor a largo plazo para nuestros usuarios,
colaboradores, y la sociedad donde operamos.
Entregar a los beneficiarios del sistema de atención pública los medicamentos

recetados por los especialistas, con un alto nivel de compromiso, y respondiendo
a las necesidades médicas en cada etapa de la enfermedad, aportando
efectivamente a su salud y bienestar. Todo lo anterior basándose en sólidos
principios y valores ministeriales.
Descripción del servicio de la empresa (Institucion)
El Centro de referencia de Salud es una institución pública que se

encarga de cubrir las necesidades básicas de la población en cuanto a
atención primaria y en algunos casos de complejidad mediana a lo que
salud se refiere.
Esta institución abarca varias comunas en la Región Metropolitana y
su principal objetivo es cubrir las necesidades de la población infantil y
adultos mayores. Uno de sus desafíos es abastecer a sus pacientes
de tratamientos crónicos o específicos con un alto grado de
compromiso, realizar campañas preventivas y de cuidado personal.
Entorno de funcionamiento
Ambiente de Desarrollo Ambiente de Pruebas Ambiente de Producción
Descripción: Descripción: Descripción:

Servidor similar al ambiente Servidor en el cual se Servidor en el cual estará
final (producción) en el cual realizan pruebas para no ver funcionando el sistema integrado.
se desarrolla el sistema afectado el negocio
integrado evitando impactos en
producción.

9
Responsable Responsable Responsable

- Jefe de proyecto - Jefe de proyecto - Jefe de proyecto
Software Software Software

- S.O. Ubuntu - S.O. Ubuntu - S.O. Ubuntu
- PHP 5.4 - PHP 5.4 - PHP 5.4
- MySQL - MySQL - MySQL
Hardware Hardware Hardware

- Intel Xeon E3 - Intel Xeon E7 - Intel Xeon E7
- Ram 4Gb - Ram 16Gb - Ram 16Gb
- 2 Discos Duro: 500Gb a - 2 Discos Duro: 2TB a - 2 Discos Duro: 2TB a
5000rpm 7200rpm 7200rpm
Minutas
ACTA DE REUNION AVANCE PROYECTO
Proyecto INTEGRACION ERP-CARRUSEL
Fecha / Hora Inicio 01-03-2017 Inicio 10:00 Final 12:30
Clasificación
Informativa Control Avance Coordinación Decisión x Otros
Convocados
Nombre Empresa Cargo Asistió

10
Lorena Mingo CRS Jefa de Farmacia SI
Pablo Molina CRS Jefe de Bodega Central SI
Andrea Poblete CRS Subdirectora Medica SI
David Fuentealba Empresa Integración Analista SI
Carlos Jeldes Empresa Integración Jefe de Proyecto SI
Rodrigo Poblete Empresa Integración Programador Senior SI
David Diaz Empresa Integración Analista SI
Temas Tratados
Nro. Descripción
1 Inicio y planificación de Integración ERP-Carrusel
Acuerdos
Nro. Descripción
1 Toma de requerimientos sobre la integración a realizar.
2 Empresa de Integración debe realizar propuesta de solución a realizar y

presupuesto.
3 Empresa se compromete a presentar módulo de receta electrónica para implementar

en box de atención.
Firmas de Validación

11
Clasificación
Informativa Control Avance Coordinación X Decisión Otros
Convocados
Pablo Molina CRS Jefe de Bodega Central NO
Temas Tratados
Nro. Descripción
1 Presentación de módulo de receta electrónica.
Acuerdos
Nro. Descripción
1 Empresa se compromete a cargar todos los códigos de farmacia al módulo

presentado para hacer pruebas
2 Se acuerda que en la próxima reunión se debe mostrar cómo será el funcionamiento
de la integración de ERP con carrusel y coordinar pruebas.

12
3 Empresa debe presentar nuevo módulo de recetas a unidades clínicas,

coordinadores, farmacia y médicos.
4 CRS entregara en próxima reunión o antes si es posible a empresa medicamentos

con límite de prescripción por tratamiento.
Clasificación
Informativa Control Avance X Coordinación Decisión Otros
Convocados
Andrea Poblete CRS Subdirectora Medica NO

13
Temas Tratados
Nro. Descripción
1 Control de avance de integración de ERP con carrusel.
Acuerdos
Nro. Descripción
1 Módulo de entrega de medicamentos para farmacia terminado y presentado
2 Módulo de receta electrónica terminado, falta presentación a funcionarios
3 Integración con carrusel lista se debe definir e iniciar el plan de pruebas de esta.
Clasificación
Informativa X Control Avance Coordinación Decisión Otros
Convocados

14
Temas Tratados
Nro. Descripción
1 Presentación de Módulos nuevos a funcionarios de la Institución.
Acuerdos
Nro. Descripción
1 Empresa se compromete a tomar en cuenta las observaciones realizadas por los

usuarios.
2 CRS hará llegar de manera formal todas las observaciones hechas por los futuros
usuarios de los nuevos módulos de entrega de medicamentos y receta electrónica.
Firmas de Validación
_____________________________ _____________________________
Lorena Mingo Andrea Poblete
Jefa de Farmacia Subdirectora Médica
_____________________________ _____________________________
David Díaz David Fuentealba
Analista Analista

15
____________________________ _____________________________
Pablo Molina Carlos Jeldes
Jefe de Bodega Central Jefe de Proyecto
_____________________________
Rodrigo Poblete
Programador
Descripción de situación actual

Actualmente el CRS despacha los medicamentos a sus pacientes a través de la
farmacia de la institución, esta farmacia tiene un carrusel dispensador de
medicamentos que ordena y mantiene alertas a los funcionarios del
abastecimiento de este para una mejor gestión de entrega hacia los pacientes. De
esta forma es posible mantener una rapidez constante ante la alta demanda de los
usuarios, así mismo los funcionarios deben intentar mantener este dispensador lo
más abastecido posible generando reportes de manera manual y inventarios casi
diarios para su mejor funcionalidad perdiendo tiempo y no entregando una buena
atención a los usuarios.
Descripción de la problemática presentada

La problemática planteada por la institución es poder disminuir los tiempos de
espera y aumentar la gestión del carrusel dispensador para que estos cambios se
vean reflejados en una mejor atención a los pacientes, el principal problema actual
es que este dispensador no tiene la información total de los stock de bodega
central por lo que no es posible asegurar que un medicamento siempre esté
disponible para los usuarios teniendo esta información conectada a
abastecimiento es posible generar alertas de compras y de reposición de este
para evitar quiebres. al estar estos sistemas conectados se podrán generar
inventarios automáticos y reportabilidad evitando que los funcionarios ocupen su
tiempo en realizarlos y enfocarse netamente en entregar una mejor atención a los
pacientes.

16
Visión de la solución propuesta

La visión de esta solución es poder acortar los tiempos de gestión y agilizar el
proceso de entrega de medicamentos a los pacientes, como también tener un
mayor control de los fármacos e insumos para evitar quiebres de stock con el fin
de administrar de mejor manera y entregar un servicio de calidad y confiabilidad.
Descripción de la solución propuesta

Nuestra solución permite integrar dos sistemas independiente que necesitaban
trabajar en conjunto para entregar mejores resultados ya sea para la
administración de la institución como hacia los pacientes. Esta integración
permitirá tener los stock de medicamentos actualizados y en tiempo real con el fin
de evitar quiebres y mala gestión de medicamentos que pueden ser de mucha
ayuda para los pacientes. El principal propósito de esta integración será entregar
cada receta a sus pacientes y hacer el descuento de ese fármaco entregado en la
base de datos de la bodega como del carrusel y con esto tener valores reales de
lo que se maneja en bodega y así poder inventariar y gestionar compras con un
nivel de exactitud mayor al 95% (actualmente este porcentaje no supera 75%).
Permitirá que los médicos y enfermeras tengan información real de un
medicamento en farmacia y en caso de que este no esté disponible entregarle una
alternativa a su paciente o pedir gestionar que ese medicamento se incorpore al
stock normal de la farmacia. también los médicos podrán tener un mayor control
de los tratamientos actuales y anteriores de cada paciente ya que el sistema
dejará un registro clínico de todo lo que el CRS le ha entregado como tratamiento
ya sea crónico o específico.
Características principales de la solución

1. Automatizar el proceso de control de medicamentos.
2. Mejorar el control, administración y entrega de existencias y disminuir el
tiempo de respuesta ante stock crítico.
3. Integrar el control de la bodega de la farmacia con el ERP.
4. Unificar la información para tener una visión general online real.
5. Integrar proceso de control de medicamentos con software del carrusel
dispensador.
6. Unificar el proceso de entrega de medicamentos con la innovación logística
adquirida.
Objetivos principales de la solución

● Reducir el tiempo de entrega de medicamentos.
● Mantener el stock controlado en línea.

17
● Agilizar los procesos internos de la unidad de abastecimiento (Bodega

central).
● Reducción de la lista de espera en farmacia.
● Mejorar el control de los tratamientos farmacológicos de los pacientes
(registro clínico).
Objetivos secundarios de la solución

● Optimización en la espacio distribución de los medicamentos en bodega.
● Utilizar mejor los recursos (Médico-Bodega-Farmacia).
● Unificar la información para tener una visión general online real.
Alcance del Proyecto

Fases del Proyecto:
1. Toma de requerimientos.
2. Desarrollo del sistema de control de inventario.
3. Creación de API REST en el ERP.
4. Test de integración.
5. Desarrollo de integración del software Dispensador Carrusel.
6. Generación módulo de receta electrónica y registro clínico
Principales entregables:
1. Sistema de control de existencias de farmacia.
2. Integración con Sistema ERP
3. Integración con Dispensador Carrusel.
4. Módulo de receta electrónica y registro clínico.
5. Capacitación del personal.
6. Documentación técnica y funcional.
Limitaciones y exclusiones
En el campo de la Salud la necesidad de la fluidez de la información es imperativa
si nos enfocamos en las enfermedades que sobreabundan, el segmento de riesgo
que existe por esa causa.
Mientras más pronto se le de prioridad, aceptación y urgencia a realizar esta
integración, los resultados reflejados en el ROI (costos) será más positivo que
negativo.

18
En cuanto a limitaciones, el desarrollo estaría enfocado a crear un sistema de

integración en farmacia y bodega o abastecimiento, por ende teniendo clara la
visión de la generación de las acciones que se realiza en cada una de las partes,
en cuanto a la limitación por parte de bodega ya sea la central y farmacia es
poblar la BD con la información para iniciar las pruebas una vez hecho
movimientos de los medicamentos y cómo se comporta en la BD estos sean por
despacho a pacientes, traslado a unidades, bodegas periféricas, devoluciones,
etc. Otra limitación podría ser la aceptación de los profesionales (Médicos) por el
sistema, generar el cambio ya que por ejemplo un médico que lleva mucho tiempo
realizando recetas de manera manual ahora lo debe hacer en un entorno virtual y
generando recetas electrónicas sin la necesidad de imprimir nada, lo que para uno
puede ser un beneficio para él una complicación.
Diseño lógico
Requisitos funcionales y no funcionales de integración.

 Validación de receta médica
 Validación de Stock disponible de medicamentos
 Entrega de medicamentos
 Actualización del stock en bodega
Descripción de los actores del sistema.

Médico Paciente Abastecimiento de la
institución.
✓ Debe incurrir a ✓ Esperar por el ✓ Manejar el Stock
medicamentos medicamento, ya sea de pedido para su
alternativos. acudiendo a consultar compra mensual.
haciendo grandes filas
✓ Quejas de sus ✓ Regular su compra
o llamando esperando
pacientes por no y el Stock crítico.
que informaciones le
encontrarse los
indique si se adquirió. ✓ Reducir los
medicamentos de las
trabajos
recetas en farmacia. ✓ Gastando de su
administrativos.
bolsillo en farmacias
✓ Ignorancia con los
pudiéndolo recibir ✓ Control total del
medicamentos a la
gratis (Sistema arsenal farmacológico
hora de generar la
público). disponible para su
receta.
distribución.

19
La espera por parte del paciente, dependerá exclusivamente de la gravedad de la

enfermedad y la urgencia para comenzar a tomar el medicamento.
Diagrama casos de Uso.

20
Descripción de los casos de uso
Nombre: Quiebre de Stock

Autor: Carlos Jeldes
Fecha: 12-04-2017
Precondiciones
1.- Ambos sistemas deben estar interconectados a través de web service, y
carrusel debe estar desprovisto de medicamento X.
EVENTO RESPUESTA DEL SISTEMA
1. El sistema de carrusel envía 2. Sistema de bodega física escucha
petición para consultar stock de petición de consulta de stock.
medicamento a bodega física.
3. Sistema de bodega consulta si tiene
5. Sistema de carrusel recibe stock.
respuesta.
4. Sistema de Bodega informa que no
posee stock
6. Sistema de bodega genera orden de
compra para compra de medicamento
EVENTOS ALTERNOS
Nombre: Reposición de stock
Nº DE LÍNEA RESPUESTA DEL SISTEMA
6.1 Stock no disponible en proveedor 6.1.1 Genera O.C. para otro proveedor
Descripción
En este caso de uso se describe el procedimiento interactivo que se produce
entre el sistema de carrusel y el de abastecimiento (bodega), al momento de no
tener medicamento.
Actores

21
Usuario, Carrusel, Sistema de Abastecimiento.

Poscondiciones
1. Sincronización de ambos sistemas.
Nombre: Actualización de stock

Autor: Rodrigo Poblete
Fecha: 12-04-2017
Precondiciones
1.- Se necesita que la cantidad de unidades del sistema de bodega, sea
suficiente para abastecer al dispensador (carrusel).
petición para reposición de petición de reposición, y queda
medicamento X que está en preparado para abastecer al carrusel.
agotamiento.
4.- Bodega recibe confirmación del
3. Funcionario accede a bodega y carrusel, y actualiza existencia
extrae la cantidad de unidades (disminución).
faltantes del medicamento. Carrusel
envía acuse de reposición a la
bodega, y actualiza su propia
existencia (aumento).
EVENTOS ALTERNOS
Nombre: Actualización de stock
4.1 Actualización de stock 4.1.1 Indica error
4.2 Solicitud de reposición en bodega 4.1.2 Vuelve al paso 2
principal
4.2.1 Indica error
4.2.2 Vuelve al paso 2
Descripción
En este caso de uso se describe el procedimiento para reposición de stock en
carrusel, con la intervención de funcionario de farmacia.

22
Actores
Poscondiciones
1. Actualización correcta para ambas existencias, y notificación de la cantidad de
unidades en ambos sistemas al funcionario.
Nombre: Verificación de Stock

Fecha: 12-04-2017
Precondiciones
petición para consultar stock de petición de consulta de stock, y envía
medicamento a bodega física. código de medicamento y cantidad del
mismo.
3. Sistema de carrusel recibe
respuesta, y verifica existencia de
stock.
EVENTOS ALTERNOS
Nombre: Verificación de Stock
2.1 Stock disponible 2.1.1 Indica error
2.2 Falta de medicamento 2.1.2 Vuelve al paso 2
2.2.1 Indica error
Descripción
entre el sistema de carrusel y el de abastecimiento (bodega), al momento de
consultar por la existencia de un medicamento X.

23
Actores
Poscondiciones
Nombre: Reposición de Medicamentos

Fecha: 12-04-2017
Precondiciones
petición al sistema de abastecimiento petición de falta de stock, y genera la
para su llenado del medicamento X. reposición del medicamento con la
cantidad correspondiente.
3. Sistema de carrusel recibe
respuesta, y espera reposición de
medicamentos.
EVENTOS ALTERNOS
Nombre: Reposición de Medicamentos
2.1 Stock No disponible 4.1.1 Indica error
Descripción
entre el sistema de carrusel y el de abastecimiento (bodega), al momento de
consultar por la existencia de un medicamento X.
Actores

24

Poscondiciones
Nombre: Generador de Reportes y Licencias

Fecha: 12-04-2017
Precondiciones
1.- El encargado debe de haber ingresado con nombre de usuario y contraseña.
1. Se presenta al usuario la pantalla 2. Sistema muestra GUI con datos del
“Reportes”. reporte solicitado
EVENTOS ALTERNOS
Nombre: Generador de Reportes y Licencias
2.1 No selecciona tipo de reporte 2.1.1 Indica error
Descripción
En este caso de uso se describe el procedimiento que permitirá generar reportes
ya sean semanales, mensuales y trimestrales de los cambios generados en la
bodega
Actores
Usuario, Sistema de Abastecimiento.
Poscondiciones

25

26
Descripción del patrón de arquitectura de integración

Orquestación
Como se puede apreciar en las siguientes páginas, la orquestación de servicios de nuestro proyecto
se inicia con la receta del doctor como mensaje de entrada, este mensaje se descompone para que
cada mensaje pueda ser distribuido y procesado a través de un enriquecedor de contenido por
cada uno de ellos (Cálculo precio base, Encontrar transportista, Encontrar producto, Manejo de
stock), Se realizan los puntos, calcular precio base, encontrar transportista, encontrar producto,
manejo de stock. Definiendo cada enriquecedor;
- Cálculo Precio Base: Tenemos un precio base por la generación de la orden, el cual es agregado
en la generación de la logística de entrega del producto.
- Encontrar Transportista: El cual es agregado al cálculo del precio total por el costo de envío y así
también el mensaje es enviado en la logística de envío.
- Encontrar productos: Los productos de la receta se agregan al cálculo del precio total, así también
a la entrega del producto.
- Manejo de stock: La cantidad de productos deben ser actualizado tanto en la bodega central
como en el carrusel, agregándose aquella información a la logística de entrega del producto y a la
reposición de medicamentos. Finalizando esto con la actualización de stock en bodega y en el
carrusel el cual debe ser mostrado también en el orden de la receta.

27
Diagrama de secuencia
Se presentan los diagramas de secuencia, por cada caso de uso.
En cada uno de éstos se puede apreciar la interacción del usuario, que es quien
desencadena la acción en el sistema.
Quiebre de stock

28
Verificación de stock

29
Reposición de medicamento

30
Actualización de stock

31
Generador de reportes y licencias

32
Diagrama de despliegue y componentes

La siguiente figura muestra, en forma general, la arquitectura e interconexión del sistema,
presentando todos los componentes imprescindibles para su funcionamiento.
La topología empleada es en diagrama de estrella, la cual concentra las conexiones de los nodos
independientes (equipo de usuario y servidores).
El único nodo dependiente de otro para la interconexión, es la impresora, utilizada tanto para
generar recetas médicas como licencias.
Los subsistemas de carrusel y bodega actúan de forma autónoma.
El desarrollo de integración contempla la comunicación entre éstos, estableciendo una interfaz

web abstracta, ocultando toda la implementación subyacente.

33
BPMN del negocio actual
El BPMN está enfocado en tres actores, que permiten transacciones completar el

recibo de remedios en farmacia por el paciente, comenzando por la emisión de la
receta por parte del Doctor, hasta la entrega del medicamento (incluyendo la firma
del acuse de recibo) o notificación de la falta de existencia del mismo:
1. Se inicia con la acción del doctor al dar la receta médica tras evaluación al
paciente en el Hospital.
2. El paciente recibe la receta y va a Farmacia a que le den los remedios que
forman parte de la receta misma.
3. Farmacia recibe la receta y verifica que el paciente este registrado en el
hospital. Si es no, rechaza la transacción, guardando los datos de la
persona y dando término al BPMN en esa acción. Si es si paciente del
hospital, busca los medicamentos si hay stock los entrega al paciente, si no
hay stock del medicamento, le da fecha probable de entrega.

34
4. Termina el BPM con dos acciones probables del paciente. Esperar el

remedio tras fecha posible, o dado la urgencia de adquirirlo comprarlo en
farmacia externa.
BPMN del negocio con las mejoras del sistema
Igual que el diagrama anterior, se realiza la entrega de medicamentos a través de una orden, la
diferencia que se puede apreciar aquí es que se agrega un sistema que integrará la bodega
principal y la bodega de la farmacia, entregando un stock completamente en línea, lo que permite
una entrega de medicamentos inmediata manteniendo actualizado el stock tanto en bodega
central como en la farmacia.

35
Plan de pruebas
Historial de Revisiones
Fecha Versión Descripción Autor

<2017-05- <1.1.0> Documento inicial <David Fuentealba>
01>
<2017-05- <1.1.1> Documento modificado <Rodrigo Poblete>
21>
<2017-06- <1.1.2> Documento modificado <David Fuentealba>
23>
Introducción
1. Propósito
El propósito de este documento es recopilar toda la información necesaria para planificar y
controlar el esfuerzo de testing.
Este “Plan de Pruebas” contempla los siguientes objetivos:
● Diseñar un plan de pruebas que logre identificar errores en los componentes especificados
en el proyecto de integración.
● Utilizaremos pruebas funcionales, pruebas de integración y pruebas estructurales.
● Utilizaremos un ambiente de pruebas de la integración que permitirá simular la integración
de ambos sistemas. Para esto, dispondremos de 2 analistas de testing para realizar las
pruebas definidas. Previamente, los analistas serán orientados en el funcionamiento del
sistema, a fin de optimizar el tiempo de pruebas.
1. Ámbito
El objetivo de este plan es poder identificar las fallas de la integración que está en proceso de
desarrollo, con el fin de poder corregir los errores o minimizarlos. El proyecto es de Integración
ERP - SGA Carrusel, y los componentes ya definidos serán los que se pondrán a prueba.
Pruebas Unitarias
Se realizarán pruebas unitarias a los componentes definidos en el proyecto tales como:
1. Quiebres de stock
2. Actualización de stock
3. Verificación de stock
4. Reposición de medicamentos
5. Validación de RUT (formato)
6. Validación de stock disponible
Pruebas Funcionales
El testing señalado es del tipo “Caja Negra”. Este tipo de pruebas busca comprobar el
comportamiento de un componente, sin inspeccionar sus detalles internos.
Con esta finalidad se utilizan datos de entrada (input), se ejecuta un componente de software y se
obtiene un resultado (output).

36
Los datos de entrada son los utilizados por las transacciones involucradas. Cada argumento de
entrada puede seleccionar uno de los siguientes datos de prueba, dependiendo este del resultado
que se desea obtener (esperado), verificando así el comportamiento del componente a probar
usando distintos valores de entrada:
● Valores normales para cada transacción (datos dentro del rango de valores aceptables).
● Valores límites para cada transacción (valores máximos y mínimo aceptable).
● Valores de borde.
● Valores ilegales (reproducción de errores para validación).
Riesgos
Algunos riesgos comunes a considerar son:
1. Documentación de especificación errónea o incompleta.
2. Lista de requerimientos inconsistente con los casos de uso.
3. Componentes a probar y componentes comunes corresponden a distintas versiones.
4. Hardware y software no funcionen correctamente.
5. Herramientas de testing automatizado estén mal configuradas.
Los riesgos serán identificados de acuerdo a un concepto de Bajo, Medio o Alto, dependiendo de la
importancia del caso de uso para el cual se está desarrollando el testing.
Así mismo, se han identificado una serie de riesgos (calificados entre 1 y 10 dependiendo de su
gravedad) los que están detallados en el artefacto “Lista de riesgos” con sus alcances y acciones,
en el presente plan, son enunciados para sugerir algunas acciones.
Matrices de Riesgos
1. Pruebas
Nº
Descripción Gravedad Acción
Riesgo
Falta de tiempo para realizar las Alto Se deben acotar las pruebas
pruebas deseadas. estableciendo factibilidad y
1
tiempo por cada una, acotando
las combinaciones de datos.
Falta de recursos necesarios para Alto Se debe intentar realizar cargas

realizar las pruebas, por ejemplo, no manuales con datos predefinidos
2
existen datos en la base de datos para pruebas.
suficientes para realizar la prueba.
Bajo rendimiento del sistema Medio Moderar la cantidad de pruebas a

3 mientras se están realizando las realizar simultáneamente.
pruebas.
Falta de conocimientos del equipo de Alto Se debe contar con

testing en la utilización de la documentación adecuada para
4
aplicación entender, rápidamente, el
funcionamiento del sistema.
5 Latencia o fallos dispositivos de red Alto Se debe establecer conexiones

de redundancia, a fin de

37
garantizar robustez en las

conexiones.
Factores medioambientales Se deben considerar factores
distractores que puedan dificultar
6 Bajo
que el plan de pruebas se lleve a
cabo cómodamente.
1. Proyecto “Integración ERP - SGA Carrusel”

Nº
Descripción Gravedad
Riesgo
Falta de tiempo para realizar las pruebas deseadas.

1 Alto
Debido a una mala estimación en el tiempo destinado para cada prueba.
Falta de recursos necesarios para realizar las pruebas, por ejemplo, no

existen datos en la base de datos suficientes para realizar la prueba.
2 Los datos, en el escenario ideal, deberían ser lo más cercano al ambiente Alto
productivo. De otra manera, o en caso que no hubiesen datos de prueba,
disminuiría la homologación del comportamiento del software en casos
reales.
Bajo rendimiento del sistema mientras se están realizando las pruebas.

3 Esto impactaría negativamente debido a que, podría, en el peor de los Medio
casos, generar un desfase de stock demasiado alto.
Falta de conocimientos del equipo de testing en la utilización de la

aplicación.
4 Alto
El equipo de testing debería conocer de antemano la funcionalidad, al
menos básica, del sistema, para optimizar el tiempo de pruebas.
Latencia o fallos dispositivos de red.
5 Las conexiones entre equipos de pruebas, dispositivos de red y servidores Alto

de aplicación y/o bases de datos, es crucial para el buen desempeño del
equipo de testing.
Factores medioambientales.
6 Se debe evitar al máximo la presencia de elementos que puedan distraer la Bajo

atención del equipo de testing, debido a la importancia de las pruebas, y del
presupuesto en tiempo estimado con anterioridad.
3. Identification del Proyecto

38
La siguiente tabla permite identificar, a modo de ejemplo, la documentación disponible para

desarrollar el “Plan de Pruebas”.
Documento Creado o Recibido o Autor u Notas
(versión / fecha) Disponible Revisado Origen
Visión del producto □Si □ Si
Especificación de □ Si □ Si
Requerimientos de Software
Modelos de Casos de Uso □ Si □ Si
Plan del Proyecto □ Si □ Si
Modelos de Diseño □ Si □ Si
Prototipos □ Si □ Si
Manuales de Usuario □ No □ No
Modelo de Negocio y Flujo □ Si □ Si
Modelo de Datos y Flujo □ No □ No
Funciones del Negocio y Roles □ No □ No
Breve Descripción
El proyecto consiste en integrar, de manera eficaz, dos sistemas que que interactúan entre sí. A
saber, estos sistemas incluyen el carrusel dispensador de medicamentos, y la bodega proveedora
de éstos.
Los actores principales de esta integración serán los usuarios de bodega central y farmacia,
quienes actualmente si bien trabajan juntos los sistemas actúan por separado por lo que la
integración permitirá agilizar los procesos de despacho y gestión administrativa de abastecimiento
y farmacia.
Este plan de pruebas permitirá testear la funcionalidad, usabilidad, seguridad y rendimiento de la
integración en su operabilidad.
Las pruebas de integración se llevarán a cabo por profesionales de pruebas (Ingenieros) con la
ayuda del personal de bodega y farmacia, quienes proporcionarán los datos necesarios, equipos e
implementos para dichas pruebas.
Requerimientos para pruebas

La siguiente lista identifica los ítems (casos de uso, requerimientos funcionales y requerimientos no
funcionales) que se han identificado como requerimientos a ser probados.
1. Casos de uso
● Quiebre de Stock
● Actualización de stock
● Verificación de Stock
● Reposición de Medicamentos
● Generador de Reportes y Licencias
1. Requerimientos funcionales
● Controlador de carrusel
● Controlador de bodega
1. Estrategia de Pruebas

39
La estrategia del plan se llevará a cabo partiendo por realizar pruebas a los casos de uso definidos
previamente en el proyecto, los cuales son mencionados en el punto 2.1 del documento. Para
continuar con los requerimientos funcionales.
Tipos de pruebas
Integridad de la base de datos y de los datos
El Administrador de Bases de Datos deberá indicar las herramientas y técnicas para ejecutar esta
prueba.
Objetivo de la Asegurar que los métodos de acceso a la base de datos (MySql) y los
prueba: procesos asociados, funcionan apropiadamente y sin riesgo de datos
corruptos, con el fin de asegurar la integridad de datos.
Técnica a utilizar: Realizar la llamada a una base de datos y ejecutar algún proceso con
datos válidos e inválidos.
Inspeccionar la base de datos para comprobar que los procesos se han
realizado correctamente, por ejemplo, enviar sentencias SELECT
recibiendo valores esperados.
Criterio de Todos los métodos de acceso a la base de datos y sus procesos deben
validación: estar sin datos corruptos (los datos validados deben poderse obtener tal
como se ingresaron.
Consideraciones La prueba puede requerir que el Administrador de bases de datos diseñe
especiales: una herramienta para acceder a los datos directamente.
Se debe utilizar una reducida cantidad de registros para facilitar la
inspección de los datos e identificar eventos erróneos.
Observaciones: El proceso se sugiere se lleve a cabo de forma manual, o contar con
archivos planos para la carga masiva.
Pruebas Funcionales
El Testing funcional se realizará sobre los requerimientos funcionales antes descritos y sus casos
de uso. Estas pruebas tienen por finalidad comprobar la funcionalidad de la aplicación a partir de
datos válidamente seleccionados sobre las transacciones del sistema.
Este tipo de comprobación se basa en las técnicas de caja negra, que permiten probar la aplicación
(y sus procesos internos) vía GUI.
Objetivo de la Asegurar la funcionalidad del conjunto de casos, incluyendo la navegación
prueba: en la aplicación, el ingreso de datos, el proceso y la recuperación
(resultados).
Que la navegación a través de los casos de prueba refleje apropiadamente
las reglas del negocio y los requerimientos, incluyendo ventana a ventana,
campo a campo y usando los métodos de acceso correctamente (tecla tab,
movimiento del mouse, etc.)
Que los objetos de las ventanas y sus características, tales como menús,
tamaño, posición, estados y foco, estén de acuerdo a los estándares.
Técnica a Ejecutar cada caso de uso, su flujo y funcionalidad usando tanto datos
utilizar: válidos como inválidos para comprobar lo siguiente:
● Que los resultados esperados ocurren cuando los datos

40
válidos son utilizados.

● Que el mensaje de error es apropiado cuando se utilizan
datos inválidos.
● Que cada regla de negocio se utiliza apropiadamente.
● Crear y modificar los procedimientos de prueba para cada
ventana, para comprobar los estados de los objetos y de la aplicación.
Criterio de ● Todas las pruebas planificadas se ejecutaron correctamente.
validación: ● Todos los defectos identificados han sido asignados.
● Cada ventana debe ser verificada para mantener la
consistencia con la versión maestra y comprobar que esté dentro de los
estándares aceptables.
Observaciones: No hay observaciones.
Pruebas de rendimiento (Performance)

Este tipo de testing medirá la respuesta del sistema ante la saturación de datos y actualización, la
idea es sobrecargarlo de manera de medir su respuesta, un ejemplo de esto es realizar varios
despachos al mismo tiempo, consultas a la BD como también generar distintos reportes de alta
información para revisar el tiempo y respuesta del sistema, también identificar cuándo se puede
saturar y generar mejoras para evitar fallas por rendimiento.
Pruebas de Seguridad y de Acceso a Datos
Prueba que permite identificar la permeabilidad del sistema hacia sus datos. con esto es necesario
hacer pruebas de Login por el cual se podrá identificar fallas en el acceso a los datos y estos ser
mal usados.
1. Recursos
Profesionales
Recursos Humanos
Rol Recursos mínimos Responsabilidades específicas /
recomendados Comentarios
(Número de
personas full-time)
Diseñador de casos de David Díaz Responsabilidades
prueba
Rodrigo Poblete ● Identificar, priorizar e
implementar los casos de prueba.
● Evaluar de forma el
esfuerzo de testing.
Testeador Pablo Aguilar Responsabilidades:
Pedro Azócar ● Ejecutar los casos de
prueba.
● Guardar estado de los
resultados.
● Recuperación de errores.
● Generar peticiones de
cambios en la documentación.
Administrador de sistema David Fuentealba Responsabilidades
del pruebas
● Administrar el sistema de
control de pruebas.
● Instalar / administrar el

41
acceso al sistema de pruebas.

Administrador de la base David Fuentealba Responsabilidades:
de datos / Encargado de la
● Administra los datos del
base de datos
prueba (Base de Datos)
● Asegurar que el entorno de
datos de prueba (base de datos) y los
valores que contiene son controlados y
mantenidos.
Diseñador Carlos Jeldres Responsabilidades:
● Identificar y definir las
operaciones, atributos y asociaciones
de las clases de prueba.
● Identificar y definir los
paquetes de prueba.
Implementador Carlos Jeldres Responsabilidades:
● Implementar las clases de
prueba y los paquetes de prueba.
1. Ambiente de pruebas
Se identifican los requerimientos de hardware, software y de comunicación necesarios para crear y
dar soporte permanente al Ambiente de pruebas. Las actividades de instalación y configuración
para el conjunto de los componentes del Ambiente de pruebas, deberán ser planificadas y
calendarizadas. Se requiere que este ambiente sea seguro, estable y dedicado exclusivamente
para las pruebas del sistema.
Se creara un ambiente de prueba llamado “Testing” que tendrá datos reales de la BD tanto de
pacientes como las existencias de bodega de farmacia y central, con el objetivo de simular todo
tipo de operaciones reales que la integración deberá realizar una vez en producción. Este ambiente
será replicado de manera idéntica al ambiente de producción.
Preparación del ambiente de pruebas
Las pruebas unitarias y de regresión deberán ser ejecutadas dentro del Ambiente de desarrollo, las
pruebas de aceptación del usuario y del sistema se ejecutarán en este Ambiente de pruebas. Este
ambiente deberá representar una configuración idéntica al Ambiente de producción o al menos,
una versión en menor escala. Esto se requiere debido a que se debe replicar el rendimiento de la
línea base y las medidas de mejoramiento relacionadas.
Diseño del ambiente de pruebas
Requerimientos mínimos de hardware para el desarrollo de las pruebas.
ITEM DESCRIPCIÓN OBSERVACIONES
HARDWARE
Estación de Pruebas
(Cliente)
Procesador CoreI3 1600 MHz o superior (Similar)
Memoria RAM 2 GB (4 GB ideal)
Espacio en Disco 320 GB
Tipo Monitor y
SVGA .28 I 800x600
Resolución

42
Tarjeta de red LAN 100/1000 MBPS

Mouse Mouse óptico 800 DPI mínimo
Tipo Enlace Red cableada UTP Cat 5e.
Servidores
Base de Datos
(pruebas)
Procesador Intel Xeon 5
Memoria RAM 16 GB 1333 MHz
10 GB para datos y 100 GB para sistema
Espacio en Disco
operativo
Tipo Monitor y
Monitor 19” con resolución 1333x768.
Resolución
Tarjeta de red Ethernet 100/1000 Mbps
Mouse Óptico de 800 DPI como mínimo
Enlace de fibra óptica de 1000 Mbps o
Tipo Enlace
superior
Aplicación (pruebas)
Procesador Intel Core i7 2.4 GHz
Memoria RAM 8 GB 1333 MHz
Espacio en Disco 2 TB, 128 GB reservado para sistema
Tipo Monitor y
UVGA 1366x768 mínimo
Resolución
Unidad de Disquete No se necesita
Ethernet 100/1000 Mbps o Wi-Fi
Tarjeta de red
equivalente
Mouse Óptico 800 DPI mínimo
Tipo Enlace Conectado a router corporativo
Impresoras
Marca y Modelo HP 3600n
Tipo Láser Color
Resolución 1200 DPI
Rendimiento 17 PPM
Conectada directamente a equipo de
Dedicación
pruebas.
RED
Topología Estrella
Medio Cable UTP Cat 5e
Velocidad 100/1000 Mbps

43
Protocolo Ethernet CSMA/CD

Módems No se necesita
10 Mbps Download
Conexión Internet
6 Mbps Upload, como mínimo.
Sistema de Respaldo /
Restauración
RAID Western Digital Caviar Black 12000
Unidad (Modelo y Marca)
RPM
Capacidad 4 TB
Ubicación Remota, en Santiago Centro
SOFTWARE
Estación de Pruebas
(Cliente)
Sistema Operativo Windows 7 Starter SP1 o superior
Rational TeamTest compuesta por Robot,
Herramienta de testing
ClearQuest TT, Test Manager
Herramienta de
Rational Rose 2000
Modelamiento
BDMA Access
Microsoft Explorer
Browser Google Chrome
Mozilla Firefox
Software de Escritorio Microsoft Office
Base de Datos (pruebas)
Sistema Operativo Windows Server 2008 RC
Software de Red Windows NOS
Dominio
Dominio/Cuenta Gestionada mediante MS ActiveDirectory
SGA
Aplicación (pruebas)
Sistema Operativo Windows 7 Starter SP1 o superior
Software de Red Windows NOS
Dominio
Dominio/Cuenta Gestionado por ActiveDirectory
SGA
Repositorios
Servidor
Dominio
Dominio / Cuenta
SGA

44
Seguridad
Diseño ambiente de pruebas

El siguiente diagrama muestra la arquitectura del Ambiente de pruebas requerido para realizar las
pruebas. La arquitectura del ambiente de pruebas debe ser, en la medida de lo posible, similar a la
arquitectura definida para el sistema en producción.
Ambiente de Usuario/Jefe de
Pruebas Pruebas
BD
Desarrollo Servidor
Integración
Ambiente de QA (Pruebas e
Desempeño
Operaciones BD Servidor Usuario Final
Integración del ambiente de pruebas y configuración

Para esta actividad se requerirá la participación de profesionales del Departamento de TICs de la
institución en cuanto a instalación, configuración y puesta en marcha del Ambiente de Pruebas.
Principalmente se requiere del responsable de la Red y Administración de Bases de Datos, de tal
forma de obtener un ambiente lo más consistente y similar al de producción, con las bases de
datos creadas y el software configurado para asegurar que el sistema funciona de acuerdo al
diseño.
Las actividades generales a ser consideradas son:
Fecha Fecha
Actividad Responsable Observaciones
Estimada Real
Prueba de red Jefe de TICs 22-05-2017 23-05- Pruebas realizadas con
2017 éxito.
Prueba de ambiente Profesional 23-05-2017 23-05- Pruebas realizadas con
de test TICs 2017 éxito.

45
Definición del Banco de Datos de Prueba

Se deberán tomar las siguientes consideraciones al momento de generar el Banco de datos.
1. Profundidad
2. Variación
3. Alcances
4. Ejecución
5. Condiciones
Se requiere conocer la documentación del sistema, de tal forma de obtener el máximo de
información para la creación de los datos.
La documentación que se requiere es:
● Documentación conceptual del sistema.
● Definición de Requerimientos.
● Especificación de software / hardware.
● Diagrama entidad - relación.
● Diagrama de casos de uso.
● Diagrama de estados.
● Diccionario de datos.
Generación de datos
La generación de los datos para las pruebas consideran los siguientes aspectos, que se deben
definir de acuerdo a los requerimientos y posibilidades de obtención. Los aspectos que se
describen a continuación, buscan que los datos sean los correctos y que cubran todos los riesgos y
situaciones necesarias.
1. Muestra de producción
Para que la muestra de datos sea realmente representativa, se deberá elegir una fecha testigo
adecuada y que posibilite la mayor cobertura de datos. En este sentido se ha elegido como fecha
testigo el 22-05-2017
Para la obtención de datos por esta vía, se deberán definir las restricciones (por motivos de
confidencialidad) y generar algún utilitario para filtrar los datos de tal forma de obtener la mayor
variabilidad de datos posible.
Además se deben considerar los siguientes aspectos para asegurar que estos datos funcionen
correctamente en el Ambiente de Pruebas, si corresponde:
● Archivos Maestros al Inicio del Día
● Tablas de Parámetros
● Interfaces de Entrada
● Archivos de Movimientos del día o del periodo
Todos estos aspectos se deben considerar en los distintos ambientes donde los datos van a ser
utilizados en las transacciones o actualizaciones.
1. Datos complementarios
En este aspecto se debe comprobar si es necesario generar datos complementarios para cubrir
todas las posibles variaciones que se puedan dar. La generación de los datos complementarios
dependerá de los datos obtenidos de producción y de la información que está en la documentación
solicitada.
Uno de los aspectos a considerar para generar datos complementarios son las fechas, para lo cual
se deberá considerar el envejecimiento de los datos a objeto de mantener la consistencia de las
pruebas e independencia de la fecha de proceso.
1. Envejecimiento de datos de prueba

46
Se debe considerar el envejecimiento de los datos de prueba, de tal forma que cumplan con la
validez de las pruebas. Los datos a envejecer serán tanto los obtenidos desde producción como los
complementarios generados para cubrir el total de las condiciones y variaciones.
Las siguientes consideraciones son eventuales y deberán considerarse sólo si es necesario.
Tienen especial relevancia ciertas fechas en que, para Jefe de TICs se realizan procesos claves,
las fechas en cuestión con sus implicancias se detallan a continuación:
Fecha Consideraciones Observaciones

01-05- Inicio del proceso de Plan de Pruebas Identificar los roles, participantes y el
2017 proyecto.
08-05- Inicio del diseño de las pruebas Análisis, casos de prueba y
2017 procedimientos para el diseño.
15-05- Inicio al proceso de implementación de Gestión del proceso de implementación
2017 las pruebas
22.05- Ejecución de las pruebas Registro de resultados (Log)
2017
05-06- Evaluación total del proceso de Análisis y toma de decisiones en base a
2017 pruebas. los resultados.
1. Actividades e Hitos del Plan de Pruebas
Esfuerz Fecha Fecha
Tarea Responsable
o Inicio Término
Plan de Pruebas
Identificar el Proyecto David Diaz 01-05- 05-05-2017
2017
Definir Estrategia David Diaz 01-05- 05-05-2017
2017
Estimar Actividades David Diaz 01-05- 05-05-2017
2017
Identificar Recursos David Diaz 01-05- 05-05-2017
2017
Documentar el “Plan de David Diaz 01-05- 05-05-2017
Pruebas” 2017
Agendar de Actividades David Diaz 01-05- 05-05-2017
2017
Revisar el “Plan de Pruebas” David Diaz 01-05- 05-05-2017
2017
Diseño de las Pruebas
Analizar Requerimientos Rodrigo 08-05- 12-05-2017
Poblete 2017
Especificar Procedimientos de Rodrigo 08-05- 12-05-2017

prueba Poblete 2017
Especificar casos de prueba Rodrigo 08-05- 12-05-2017

Poblete 2017
Revisar Cobertura de los Rodrigo 08-05- 12-05-2017

requerimientos de prueba Poblete 2017
Implementación de las Pruebas

47
Establecer Ambiente de David 15-05- 19-05-2017

Implementación Fuentealba 2017
Desarrollar los Procedimientos David 15-05- 19-05-2017
de Prueba Fuentealba 2017
Probar y depurar los David 15-05- 19-05-2017
procedimientos de prueba Fuentealba 2017
Modificar los procedimientos de David 15-05- 19-05-2017
prueba Fuentealba 2017
Ejecución de las pruebas

Ejecutar pruebas Rodrigo 22-05- 26-05-2017
Poblete 2017
Comprobar resultados Rodrigo 22-05- 26-05-2017

esperados Poblete 2017
Investigar resultados Rodrigo 22-05- 26-05-2017

inesperados Poblete 2017
Registrar defectos (log) Rodrigo 22-05- 26-05-2017

Poblete 2017
Re-Ejecutar las pruebas Rodrigo 22-05- 26-05-2017

Poblete 2017
Evaluación de las pruebas

Revisar el Log de pruebas Carlos Jeldres 05-06- 09-06-2017
2017
Evaluar cobertura de los casos Carlos Jeldres 05-06- 09-06-2017
de prueba 2017
Evaluar defectos Carlos Jeldres 05-06- 09-06-2017
2017
Reportar defectos Carlos Jeldres 05-06- 09-06-2017
2017
1. Entregables
Casos de Prueba.
1.- Quiebre de Stock
Caso de prueba Quiebre de stock
Identificador caso
CP0001_QuiebreDeStock.
de prueba
Gestión del dispensador, y orquestador/integrador de
Función probar
Dispensador y Bodega.
Objetivo El objetivo de esta prueba es, verificar si la cantidad de un

48
medicamento X ha llegado a 0.
Verificar si un medicamento X ha agotado su stock (existencia =
Descripción
0).
Criterios de éxito Respuesta boleana por parte del sistema.

Caídas de sistema.
Criterios de falla
Imposibilidad de conexión a base de datos.
Se necesita que la conexión a base de datos se haya establecido

Precondiciones correctamente., haberse autenticado, contar con los permisos de
modificación.
Perfil del usuario Usuario de testing con privilegios para modificar.
Necesidades para Conexión a base de datos y usuario con privilegios

el caso de prueba correspondientes para modificación.
Autor
Fecha de creación
No
Usuario del sistema Sistema
paso
Sistema revisa de
forma periódica el
1
stock del
dispensador.
En caso que algún
Flujo del caso de medicamento
prueba 2 quede con stock 0,
se intenta reponer
desde la bodega.
En caso que un
medicamento no se
pueda reponer, se
3
genera una orden
de compra al
proveedor.
Post condiciones

49
2.- Actualización de Stock

Caso de prueba Actualización de stock
Identificador caso
CP0002_ActualizacionDeStock.
de prueba
Función probar Interacción entre bases de datos de dispensador y bodega.

Este caso de prueba tiene como objetivo reabastecer al sistema
Objetivo dispensador, sustrayendo de la bodega X cantidad de elementos
para medicamento Y.
Descripción
Criterios de éxito Notificación al usuario, y actualización de las bases de datos.
Error de conexión.
Criterios de falla
Caídas del sistema.
Conexión establecida a bases de datos.
Precondiciones Autenticación correcta d el usuario.
Usuario debe poseer privilegios de modificación.
Perfil del usuario Usuario de testing con permisos de modificación.

Necesidades para Conexión a base de datos y usuario con privilegios
el caso de prueba correspondientes para modificación.
Autor
Fecha de creación
Flujo del caso de No

prueba paso
Usuario solicita reposición por X
1
elementos, de un medicamento Y.
Sistema captura
parámetros, y
2
consulta a base de
datos de bodega.
3 En caso que bodega
cuente con el
medicamento y
stock solicitado,
abastece a carrusel,
actualizando las
bases de datos

50
tanto de éste como

de bodega.
Mensaje de notificación por medicamento no encontrado o déficit
Post condiciones de existencia, o mensaje de actualización correcta en bases de
datos, y reabastecimiento de dispensador.
3.- Verificación de Stock

Caso de prueba Verificación de stock
Identificador caso
CP0003_VerificaStock.
de prueba

Comprobar la correcta verificación del stock solicitado para
Objetivo
reabastecimiento del carrusel.
Descripción Consulta de la cantidad de elementos de un medicamento X.

Envío de mensaje advirtiendo la cantidad de elementos del
Criterios de éxito
medicamento.
Criterios de falla Caídas del sistema, mensajes de error desde la base de datos.
Autenticación por parte del usuario, y selección de medicamentos
Precondiciones
por parte de éste.
Perfil del usuario Usuario de testing con privilegios de visualización.
Necesidades para Conexión a base de datos.

el caso de prueba Datos de entrada ID de medicamento.
Autor
Fecha de creación

prueba paso
Usuario, una vez autenticado,
solicita información de cantidad
1
de unidades para medicamento
X.
2 Generar mensaje
de error por déficit
en stock, o mensaje
de aprobación para

51
reabastecimiento.
Post condiciones

52
4.- Reposición de medicamento

Caso de prueba Reposición de medicamento
Identificador caso
CP0004_ReposicionMedicamento.
de prueba

El objetivo de esta prueba es, mediante petición, actualizar el
Objetivo stock de un medicamento X de acuerdo a los parámetros
ingresados por el usuario (medicamento y cantidad).
Caso de pruebas que repone el dispensador, proveyendo desde la

Descripción
bodega.
Se actualizan las bases de datos de bodega y dispensador, y se
Criterios de éxito despliega mensaje a usuario con el mensaje satisfactorio
correspondiente.
Criterios de falla Error de conexión a base de datos.

Conexión a base de datos establecida.
Precondiciones
Correcto ingreso de datos por parte del usuario.
Perfil del usuario Usuario de testing.

Necesidades para
Usuario con perfil de modificación.
el caso de prueba
Autor
Fecha de creación

prueba paso
El usuario indica la cantidad X
1
para el medicamento Y.
Sistema captura
valores ingresados,
y, gestiona la
reposición,
2 sustrayendo la
cantidad indicada
de la bodega y,
adicionándola al
dispensador.
3 Actualización de las
bases de datos de

53
bodega y de
dispensador.
En el resultado se debiera reflejar, con un mensaje de error, en
caso que los datos se hayan ingresado erróneamente, que el stock
Post condiciones
de bodega no satisfaga lo requerido, o con la correcta
actualización de las bases de datos bajo una transacción exitosa.
5.- Generación de reportes y licencias

Caso de prueba Generación de reportes y licencias
Identificador caso
CP0005_ReposicionMedicamento.
de prueba
Función probar Gestor de reportería
La siguiente prueba tiene por objetivo generar reportes de
Objetivo
acuerdo a la información almacenada en las bases de datos.
Descripción
Se genera reporte con las siguientes posibles frecuencias:
Criterios de éxito - Inmediata

- Semanal
- Mensual
- Trimestral
Problemas de conexión a base de datos.
Criterios de falla
Autenticación satisfactoria de usuario.

Precondiciones
Privilegios suficientes para visualizar datos y generar reportes.
Necesidades para Contar con información para reportabilidad, conexión a base de

el caso de prueba datos y usuario con privilegios correspondientes.
Autor
Fecha de creación
prueba paso
Escoge la opción de generar

1
reportes.
2 Genera reportes
con la información

54
disponible, o
mensaje de error al
usuario.
Post condiciones

55
6.- Validación de stock mínimo

Caso de prueba Validación de stock mínimo
Identificador caso
CP0006_ValidacionStockMinimo
de prueba

Esta prueba tiene como objetivo verificar la existencia mínima
Objetivo
aceptable del dispensador.
Se comprueba si el stock del dispensador contiene menos de 50

Descripción
unidades de un medicamento X.
Criterios de éxito Mensaje al usuario.
Problemas de conexión a base de datos.

Criterios de falla
Autenticación satisfactoria de usuario.
Precondiciones
Privilegios suficientes para visualización.

Necesidades para Contar con información para reportabilidad, conexión a base de
el caso de prueba datos y usuario con privilegios correspondientes.
Autor
Fecha de creación
No
paso
Usuario consulta por stock
1
mínimo de medicamento X.
Sistema captura
Flujo del caso de código de
prueba medicamento, y
2
consulta si existen
menos de 50
unidades.
Mensaje de
3
notificación.
Post condiciones

56
7.- Validación de stock no negativo

Caso de prueba Validación de stock no negativo
Identificador caso
CP0007_ValidacionStockNoNegativo
de prueba

Objetivo Validación de stock no negativo.
Descripción Comprobar que el stock solicitado por el usuario no sea negativo.

Mensaje informativo a usuario en caso que el stock sea negativo,
Criterios de éxito
o, en caso stock correcto, se procede al siguiente paso del flujo.
Criterios de falla Caídas del sistema, mensajes de error desde la base de datos.
Autenticación de usuario.
Precondiciones Usuario con privilegios necesarios.
Conexión a base de datos establecida.
Perfil del usuario Usuario de testing con privilegios de administración.

Conexión a base de datos iniciada.
Necesidades para
Usuario correctamente autenticado.
el caso de prueba
Datos de entrada (ID de medicamento y cantidad de unidades)
Autor
Fecha de creación
No
paso
Usuario solicita stock para
1 reabastecimiento (valor
Flujo del caso de numérico, entero).
prueba Generar mensaje
de notificando si la
2
cantidad ingresada
es negativa.
Se envía mensaje de error al usuario en caso que la cantidad de

Post condiciones
elementos sea inferior a 0.

57
8.- Validación de RUT

Caso de prueba Validación de RUT
Identificador caso
CP0008_ValidacionRut
de prueba
Función probar Sistema de autenticación.

Objetivo Validar el RUT mediante un patrón verificador.
Comprobar el correcto ingreso del RUT en formato

Descripción
correspondiente (12345678-X).
Criterios de éxito Ejecución de autenticación.
Caídas del sistema, mensajes de error desde la base de datos,

Criterios de falla
usuario inexistente o datos erróneos.
Datos de prueba:
Precondiciones - RUT
- Contraseña
Conexión con base de datos establecida
Perfil del usuario Usuario de testing.
Necesidades para Conexión a base de datos iniciada.

el caso de prueba Datos de entrada para log-in (RUT y contraseña)
Autor
Fecha de creación
prueba paso
1 Usuario ingresa RUT y

contraseña para autenticarse.
El RUT contempla un máximo de

10 dígitos, considerando los
siguientes como válidos:
- Dígitos del 0 al 9.
- Guión (-)
Dígito verificador, o letra K (sólo

se considera en mayúscula).

58
Generar mensaje
de error por RUT
incorrecto, usuario
no válido, o
2
conceder permisos
luego de
autenticación
satisfactoria.
Post condiciones Acceso de usuario a elementos bajo el privilegio correspondiente.

Reportes.
Una vez terminado los casos de pruebas se entregara una serie de reportes con los
resultados y análisis de estos, como también los Logs
1. Plan de pruebas
Se entregaran reportes con la finalidad de revisar y analizar las pruebas realizadas
Criterio de entrada para el “Plan de pruebas”
Para dar comienzo al plan de pruebas debe estar disponible el ambiente de pruebas y ser idéntico
al ambiente de producción para tener un análisis real de lo que se prueba, con esto como mínimo
se puede dar inicio al plan y al ingreso de datos para realizar el test.
Criterio de salida para el “Plan de pruebas”
El criterio para finalizar el plan se base en encontrar la mayor cantidad de errores sea necesario en
las pruebas realizadas, con eso el análisis busca replicar todo los posibles casos que se pueden
producir en el proceso de producción de la integración, es por esto que es necesario realizar todas
las pruebas necesarias que se estimen convenientes con el fin de poder identificar los errores
mencionados, si esto no satisface el análisis satisfactorio debe continuar el proceso de pruebas
hasta un resultado eficaz.
Criterio de suspensión y resumisión
En caso de que la respuesta esperada del sistema exceda el tiempo estipulado se puede tomar
como criterio de suspensión de la prueba.
Otra causa de suspensión es la falta de personal calificado para desarrollar las pruebas, como
también que no se pueda simular un ambiente de pruebas lo más cercado al de producción.
1. Resultados de las pruebas
Los resultados de las pruebas estan identificados en la plantilla de pruebas con cada caso de
estas.
1. Reporte de defectos
Este reporte se puede identificar y registrar con los datos y mensajes que arrojo el sistema cuando
se realizaron las pruebas programadas y ya detalladas, ejemplo Mensaje de errores y de ejecución
exitosa, carga de reportes, etc.
Tareas del proyecto
La siguiente lista muestra las tareas relacionadas con el “Plan de pruebas”:
✓ “Plan de pruebas” (preliminar, al inicio del proyecto)

✓ Identificar requerimientos para el testing
✓ Identificar los riesgos, cuantificar impacto
✓ Desarrollar la estrategia de pruebas
✓ Identificar los recursos para las pruebas
✓ Generar “Plan de Pruebas” detallado
✓ Diseño general de las pruebas
✓ Análisis de carga
✓ Identificar y describir los casos de prueba
✓ Identificar y estructurar los procedimientos de prueba

✓ Revisar y accesar la cobertura de las pruebas
✓ Implementar las pruebas
X Grabar o programar los scripts de las pruebas, si aplica
✓ Identificar las funcionalidades a probar, específicos en el modelo de diseño e

implementación
X Establecer el conjunto de datos externos
✓ Ejecutar las pruebas
✓ Ejecutar los procedimientos de prueba
✓ Evaluar la ejecución de las pruebas
✓ Comprobar los resultados
✓ Investigar los resultados inesperados
✓ Registro de defectos, Informe de Resultados
✓ Evaluar las pruebas
✓ Evaluar la cobertura de los casos de prueba
✓ Evaluar la cobertura del código
✓ Analizar defectos
Pruebas de rendimiento (performance)

Para esto, se definen las transacciones de acuerdo a los casos de uso específicos que se espera
que un actor del sistema realice usando un conjunto de datos para agregar o modificar
transacciones.
Comprobar la conducta de rendimiento para las transacciones

seleccionadas o funcionalidades bajo las siguientes condiciones:
Objetivo de la
prueba: - Una carga de trabajo normal.
- Una sobrecarga de trabajo.
Usar los procedimientos de pruebas desarrollados para el testing
funcional.
Modificar los archivos de datos para aumentar las transacciones o los
script de robotización para incrementar el número de iteraciones de cada
Técnica a usar:
transacción.
Los script deberán correr en una máquina (la mejor referencia es un solo
usuario y una única transacción) y repetirla con múltiples clientes
(virtuales o reales).
Una Transacción / Un Usuario: La finalización exitosa de los scripts de
prueba sin ninguna falla dentro del tiempo esperado (por transacción en
Criterio de forma independiente).
validación:
Múltiples Transacciones / Múltiples Usuarios: La finalización exitosa de los
scripts de prueba sin ninguna falla dentro tiempo estimado.
Consideraciones La extensión del testing de rendimiento requiere tener en background la
carga de trabajo en el servidor.
Existen varios métodos que se pueden usar para realizar esto como por
ejemplo:
Gatillar transacciones directamente al servidor, normalmente en forma de
llamadas de SQL.
Crear una carga de usuarios virtuales para simular (normalmente varios
cientos) los clientes. Para esto se utilizan herramientas de emulación de
terminales remotas para lograr esta carga. Esta técnica también puede
especiales:
usarse para someter a la red a un alto tráfico.
Usar múltiples clientes físicos, cada uno corriendo los Test scripts para
agregar una carga al sistema.
El testing de rendimiento debería realizarse en una máquina dedicada o
en un tiempo dedicado. Esto permite un control total y una exacta
medición.
Las bases de datos utilizadas para realizar el testing de rendimiento
deberán ser del tamaño equivalente a las de producción o a escala similar.
Observaciones:
Pruebas de seguridad y de control de acceso

En este punto, analizaremos los accesos y/o privilegios, considerando los distintos perfiles
utilizados en el sistema (administrador y usuario).
Este testing se enfoca en dos áreas claves de la seguridad:
● Seguridad a nivel de la Aplicación, incluyendo acceso a los datos o funciones de negocio, y
● Seguridad a nivel del Sistema, incluyendo el autenticación (login) y/o acceso remoto al
sistema.
● La seguridad a nivel de la aplicación, asegura que, sobre la base de la seguridad deseada,
se restringen a los usuarios a ciertas funciones o casos de uso específicos o se les limita el
acceso a datos disponible para ellos.
● La seguridad a nivel de sistema, asegura que sólo los usuarios definidos en el sistema son
capaces de acceder a la aplicación y sólo a través de entradas apropiadas.
Seguridad a Nivel de Aplicación: comprobar que un usuario puede

acceder sólo a las funcionalidades y datos para las cuales ese tipo de
Objetivo de la usuario tiene permiso (perfiles).
prueba:
Seguridad a Nivel de Sistema: comprobar que sólo esos usuarios con
acceso al sistema y aplicación tienen permitido el acceso (autenticación).
Nivel de Aplicación: Identifique y liste cada tipo de usuario y las
funcionalidades y datos de cada tipo para las cuales tiene permiso.
Cree pruebas para cada tipo de usuario y verifique cada permiso creando
transacciones específicas para cada usuario.
Técnica a usar: Modifique los tipos de usuarios y vuelva a ejecutar los casos de prueba
para los mismos usuarios. En cada caso verifique si las funcionalidades y
los datos están correctamente disponibles o denegados.
Acceso a Nivel de Sistema: vea las consideraciones especiales más
abajo.
Criterio de Para cada tipo de usuario conocido, las funcionalidades y los datos
validación: correctos debieran estar disponibles y todas las transacciones ejecutadas
debieran ejecutarse de acuerdo a lo esperado.
El acceso al sistema debería ser comprobado con el administrador de la
Consideraciones red o del sistema.
especiales: Este testing quizás pueda requerir de la participación del administrador
de la red o del sistema.
Observaciones:
Diseño físico
Métodos Web Services

• validaLogin();
• agregaPoducto();
• agregaUsuario();
• modificaUsuario();
• cuentaUsuarios();
• listaUsuarios();
• cuentaProductos();
• actualizaStock();
• listaProductos();
• actualizaStockFarmacia();
Consumo de Web Services externo

• http://www.dneonline.com/calculator.asmx?WSDL
WS con métodos matemáticos, como suma, resta, multiplicación y división
Consumo de Web Services personal

• Md5();
Para encriptación de claves de cuenta.
Pantalla de implementación de mantenedores y consultas

Login
Perfil Administrador
Perfil Administrador (Menú Productos)
Perfil Administrador (Menú Usuarios)

Perfil Usuario
Perfil Usuario (Menú Productos)
Funciones
Función Agregar Producto
Función Traspasar Productos de Bodega a Farmacia

Función Lista Producto
Función Entrega de Producto
Función Agregar Producto

Función Lista de Usuarios
Función Mantenedor de Usuarios

Web Service Personal
Web Service Externo
Web Service Java
Diseño de orquestación de servicios mediante BPEL Conceptual

El sistema, en su completitud, cuenta con webservices en Java, los cuales son
invocados mediante la aplicación .NET.
Se consideran WebServices propios, y otros consumibles de dominio público.
La imagen presenta en su interior, la intercomunicación que se establece cada vez
que el usuario desencadena una petición, tomando como ejemplo el proceso de
login, con el consecuente acceso a los WebServices en caso que éste se
desarrolle de forma satisfactoria, o con el la desconexión abrupta en caso de fallo
de autenticación.
Conclusión.
Al evaluar tras la toma de requerimientos, las necesidades reales que posee el
hospital son de atención más eficiente (paciente), y los problemas que surgen por
la desconexión de comunicación de bodega, farmacia y doctor, en cuanto al
manejo de Stock de los medicamentos y los problemas que gatillan en el paciente,
cuando el remedio dado en receta no está en disponible y debe esperar o acudir
las veces que sean necesarias gastando recursos y tiempo o teniendo que
comprar en farmacias externas a un precio bastante más elevado que lo que se
ofrece en la farmacia del hospital.
Por otro lado, se cumpliría con la necesidad de optimizar el procedimiento, y
menguar las intervenciones manuales por parte del personal de farmacia,
invirtiendo en una solución escalable y de fácil mantención preventiva y evolutiva,
asegurando así la calidad y eficiencia del servicio.
Anexos (Minutas).
Bibliografía
Apuntes en clases.
Drive privado compartido por profesor Guillermo Pinto.
Documentación unidades anteriores sobre el proyecto.

Carrusel Integration

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Carrusel Integration

Enviado por

Direitos autorais:

Formatos disponíveis

1

Integración ERP – SGA Carrusel.

Integración ERP – SGA Carrusel.

Integración ERP – SGA Carrusel.

Integración ERP – SGA Carrusel.

Requisitos del negocio

Integración ERP – SGA Carrusel.

módulo de receta electrónica y registro clínico del paciente. A la vez, se

Integración ERP – SGA Carrusel.

Objetivos de negocio y criterios de éxito

El Departamento de Promoción de Salud y Participación Ciudadana,

Integración ERP – SGA Carrusel.

Como organismo de administración de medicamentos, los esfuerzos de la

Entregar a los beneficiarios del sistema de atención pública los medicamentos

Descripción del servicio de la empresa (Institucion)

El Centro de referencia de Salud es una institución pública que se

Ambiente de Desarrollo Ambiente de Pruebas Ambiente de Producción

Descripción: Descripción: Descripción:

Integración ERP – SGA Carrusel.

Responsable Responsable Responsable

Software Software Software

Hardware Hardware Hardware

ACTA DE REUNION AVANCE PROYECTO

Proyecto INTEGRACION ERP-CARRUSEL

Fecha / Hora Inicio 01-03-2017 Inicio 10:00 Final 12:30

Informativa Control Avance Coordinación Decisión x Otros

Nombre Empresa Cargo Asistió

Integración ERP – SGA Carrusel.

Lorena Mingo CRS Jefa de Farmacia SI

Pablo Molina CRS Jefe de Bodega Central SI

Andrea Poblete CRS Subdirectora Medica SI

David Fuentealba Empresa Integración Analista SI

Carlos Jeldes Empresa Integración Jefe de Proyecto SI

Rodrigo Poblete Empresa Integración Programador Senior SI

David Diaz Empresa Integración Analista SI

1 Inicio y planificación de Integración ERP-Carrusel

1 Toma de requerimientos sobre la integración a realizar.

2 Empresa de Integración debe realizar propuesta de solución a realizar y

3 Empresa se compromete a presentar módulo de receta electrónica para implementar

ACTA DE REUNION AVANCE PROYECTO

Integración ERP – SGA Carrusel.

Proyecto INTEGRACION ERP-CARRUSEL

Fecha / Hora Inicio 15-03-2017 Inicio 10:00 Final 12:30

Informativa Control Avance Coordinación X Decisión Otros

Nombre Empresa Cargo Asistió

Lorena Mingo CRS Jefa de Farmacia SI

Pablo Molina CRS Jefe de Bodega Central NO

Andrea Poblete CRS Subdirectora Medica SI

David Fuentealba Empresa Integración Analista SI

Carlos Jeldes Empresa Integración Jefe de Proyecto SI

Rodrigo Poblete Empresa Integración Programador Senior SI

David Diaz Empresa Integración Analista SI

1 Presentación de módulo de receta electrónica.

1 Empresa se compromete a cargar todos los códigos de farmacia al módulo

Integración ERP – SGA Carrusel.

3 Empresa debe presentar nuevo módulo de recetas a unidades clínicas,

4 CRS entregara en próxima reunión o antes si es posible a empresa medicamentos

ACTA DE REUNION AVANCE PROYECTO

Proyecto INTEGRACION ERP-CARRUSEL

Fecha / Hora Inicio 29-03-2017 Inicio 10:00 Final 12:30

Informativa Control Avance X Coordinación Decisión Otros

Nombre Empresa Cargo Asistió

Lorena Mingo CRS Jefa de Farmacia SI

Pablo Molina CRS Jefe de Bodega Central SI