facultad de ingenieríarepositorio.utp.edu.pe/bitstream/utp/1296/1/frarossar espinoza_trabajo... ·...
TRANSCRIPT
“Facultad de Ingeniería
“OPTIMIZACIÓN DE LA
ARQUITECTURA DE SOFTWARE
PARA OPTIMIZAR LA
COMUNICACIÓN
TRANSACCIONAL EN EL ÁREA
DE LOGÍSTICA DE ESSALUD EN
LA CIUDAD DE LIMA - 2017”
Bachiller:
Frarossar, Espinoza Arangoitia
Para optar el Título Profesional de Ingeniero
de Sistemas e Informática
Lima – Perú
2018
Ingeniería de Sistemas e Informática”
Programa Especial de Titulación:””
2
3
DEDICATORIA
Dedico este trabajo a todas las personas que puedan beneficiarse del
contenido.
4
AGRADECIMIENTO
Agradezco a mi madre y a todas las personas que fueron partícipes en la
elaboración de este proyecto.””
5
RESUMEN
La empresa SALOG brinda servicios de logística a EsSalud. SALOG realiza
sus transacciones logísticas de medicamentos mediante un sistema propio,
el cual se sincroniza con el sistema SAP que pertenece a EsSalud, con el
fin de tener la misma información. La sincronización entre ambos sistemas
se daba mediante el modelo Middleware Orientado a Mensajes (MOM) que
procesaba las transacciones mediante cola, esto generaba muchos pasos
de por medio para comunicarse con SAP y encolamiento de transacciones
ya que se atendían uno por uno.
El presente trabajo tiene por objetivo optimizar el proceso de atención de
las transacciones que se dan entre el sistema de SALOG y entre el sistema
de EsSalud (SAP), con el fin de evitar el encolamiento y disminuir las quejas
de los usuarios.
Entre los métodos para lograr el objetivo principal, se analizó el flujo de
comunicación entre ambos sistemas, se restructuró la arquitectura de
comunicación utilizando un archivo .jar elaborado en el lenguaje de
programación java instalado en un servidor y llamado por una tarea
programada. Esta nueva estructura realiza que los sistemas se comuniquen
más rápidamente y que se procese varias transacciones al mismo tiempo.
No generándose así encolamiento de transacciones.
Palabras claves: Middleware Orientado a Mensajes (MOM), archivo jar,
Tareas Programadas.
6
INDICE
Tabla de contenido
RESUMEN.................................................................................................5
INDICE ......................................................................................................6
CAPÍTULO 1 ..............................................................................................9
ASPECTOS GENERALES. .......................................................................9
1.1. Definición del problema. .............................................................10
1.1.1. Descripción del problema. ....................................................10
1.1.2. Formulación del Problema. ...................................................12
1.1.3. Problemas Específicos .........................................................12
1.2. Definición de Objetivos ...............................................................12
1.2.1. Objetivo General. .................................................................12
1.2.2. Objetivos Específicos. ..........................................................12
1.3. Alcances y Limitaciones. .............................................................12
1.4. Justificación ................................................................................13
CAPITULO 2 ............................................................................................14
FUNDAMENTO TEÓRICO ......................................................................14
2.1. Marco Teórico .............................................................................15
2.1.1. Antecedentes del estudio .....................................................15
2.1.2. Metodología .........................................................................16
2.1.3. Lenguaje de Programación ..................................................25
2.1.4. Gestor de Base de Datos .....................................................27
2.2. Marco conceptual .......................................................................29
Definición de conceptos ....................................................................29
2.3. Marco Metodológico ...................................................................30
2.3.1. Metodología SCRUM ...........................................................30
2.3.2. Beneficios ............................................................................30
2.3.3. Roles de Scrum ....................................................................31
2.3.4. Elementos de Scrum ............................................................32
2.3.5. Eventos de Scrum ................................................................33
2.3.6. Roles de usuario ..................................................................35
7
2.3.7. Historias de Usuario .............................................................35
CAPÍTULO 3 ............................................................................................37
DESARROLLO DE LA SOLUCIÓN .........................................................37
3.1. Breve descripción de la Solución ................................................38
3.2. Diagrama de flujo ........................................................................41
3.3. Requerimientos Funcionales.......................................................42
3.4. Roles de usuario .........................................................................44
3.5. Visual Story Mapping ..................................................................45
3.5.1. Identificación de los Procesos de Negocio ...........................45
3.5.2. Identificación de Funcionalidades .........................................45
3.6. Identificación de Entregas ...........................................................48
3.6.1. MVP (Entrega 1) ..................................................................48
3.6.2. MVP (Entrega 2) ..................................................................49
3.6.3. MVP (Entrega 3) ..................................................................49
3.7. Historias de Usuarios ..................................................................50
3.8. Plan de Entregas (Release Plan) ................................................54
3.9. Cronograma ................................................................................57
3.10. Base de datos .........................................................................58
CAPITULO 4 ............................................................................................59
RESULTADOS ........................................................................................59
4.1. Resultados ..................................................................................60
4.1.1. Resultados ...........................................................................60
4.1.2. Presupuesto .........................................................................64
FUENTES DE INFORMACIÓN ................................................................66
CONCLUSIONES ....................................................................................68
ANEXOS .................................................................................................69
Anexo 1: Flujo de comunicación entre sistema de SALOG y SAP ........69
8
Ilustraciones
Ilustración 1: Diagrama de Ishikawa ........................................................11
Ilustración 2: Iteración en RUP ................................................................18
Ilustración 3: Fases del Método RUP .......................................................20
Ilustración 4: Estructura de RUP ..............................................................21
Ilustración 5: SCRUM ..............................................................................22
Ilustración 6: Metodología SCRUM ..........................................................23
Ilustración 9: Sprint Backlog ....................................................................32
Ilustración 10: Diagrama de propuesta de solución..................................39
Ilustración 11: Flujo de Proceso de Cola ..................................................41
Ilustración 12:Visual Story Mapping .........................................................47
Ilustración 13: Base de datos del proyecto ..............................................58
Ilustración 14: Mínimo de transacciones por día ......................................61
Ilustración 15: Máximo de transacciones por día .....................................62
Ilustración 16: Incidencias al mes por medio de tickets ............................62
Ilustración 17: Curva S ............................................................................64
Ilustración 18: Comunicación antigua entre SALOG y SAP .....................69
Tablas
Tabla 1: Comparación de Metodologías ..................................................24
Tabla 2: Comparación de Lenguajes de Programación ...........................26
Tabla 3: Comparación de Gestor de BD ..................................................28
Tabla 4: Comparación de arquitecturas del sistema ................................60
9
CAPÍTULO 1
ASPECTOS GENERALES.
10
1.1. Definición del problema.
1.1.1. Descripción del problema.
El boletín de la Organización Mundial de Salud (OMS, 2012) en su
publicación “Escasez de medicamentos: un problema mundial complejo”
afirma que los desabastecimientos de medicamentos son reconocidos
como un problema global.
A nivel de Perú, EsSalud que es donde hay la mayor cantidad de
asegurados realizó un contrato de Asociación Público Privada (APP) con la
empresa SALOG S.A. quien le brinda Servicios de Gestión concerniente al
Almacenamiento, Distribución y Entrega de Materiales en la Red de
Almacenes y Farmacias de la provincia de Lima y de la provincia
constitucional del Callao.
Este contrato entre SALOG y EsSalud tiene por finalidad realizar mejoras
en el servicio de entrega de medicamentos a pacientes, realizando una
entrega oportuna de medicinas y mantener abastecidas las farmacias de la
institución.
La empresa SALOG implementó un sistema propio en el Almacén Central
y en 16 centros asistenciales de EsSalud. Este sistema mantiene
comunicación con el sistema SAP de EsSalud para sincronizar datos de las
transacciones generadas en el transcurso del día con la finalidad de que
ambos muestren la misma información.
Es en este punto es donde se menciona el concepto de la comunicación
entre sistemas distribuidos, sistemas con diferente estructura,
programación que deben compartir información. Debido a la gran cantidad
de transacciones a sincronizar, la empresa manejaba una atención de
transacción apoyada en el modelo Middleware Orientado a Mensajes
(MOM) que procesa transacciones mediante colas; este modelo genera
muchos pasos de por medio para comunicarse con SAP y encolamiento de
transacciones ya que se procesaban uno por uno.
11
Cabe mencionar que algunos centros de salud presentaron algunos
problemas de abastecimiento, generando así que los pacientes no tengan
sus medicinas correspondientes.
Causa efecto del problema: Ishikawa
CAUSAS
• Tecnología
o Mala arquitectura de comunicación entre sistema de SALOG
y SAP.
o Sistemas no muestran la misma información.
o Proceso de transacciones uno por uno, encolamiento.
• Personal
o Mala coordinación entre analista y centros hospitalarios de
EsSalud.
o Falta de capacitación en el uso del sistema.
• Materiales
o Problemas en los laboratorios
• Medio Ambiente
o Accesos difíciles a centros de salud
EFECTOS
Desabastecimiento de medicinas en los centros de EsSalud.
Ilustración 1: Diagrama de Ishikawa
12
1.1.2. Formulación del Problema.
¿En qué medida la implementación ayudará a optimizar el
procesamiento de transacciones en el área de logística de EsSalud
permitiendo reducir el riesgo de desabastecimiento de
medicamentos en los centros de salud?
1.1.3. Problemas Específicos
▪ ¿En qué medida la mala arquitectura de comunicación entre
sistema SALOG y SAP (EsSalud) influye en la entrega de
medicamentos?
▪ ¿En qué medida el procesamiento de transacciones “uno por
uno” perjudica la sincronización de data generando
encolamiento?
1.2. Definición de Objetivos
1.2.1. Objetivo General.
Optimizar la arquitectura de comunicación transaccional en el
área de logística entre SALOG y EsSalud.
1.2.2. Objetivos Específicos.
• Diseñar una nueva arquitectura de comunicación entre el
sistema de SALOG y SAP.
• Optimizar el tiempo de sincronización de datos entre ambos
sistemas procesando varias transacciones al mismo tiempo.
1.3. Alcances y Limitaciones.
El alcance del presente proyecto, comprende la construcción de una nueva
arquitectura de comunicación entre el sistema de la empresa SALOG con
el sistema SAP.
La nueva arquitectura se base en la creación de un archivo codificado en
el lenguaje de programación JAVA el cual procesará las transacciones
generadas en el Almacén Central y en los Centros hospitalarios.
13
A diferencia de la arquitectura anterior, ahora se procesarán varias
transacciones a la vez, dando como resultado una sincronización más fluida
y que no genera encolamiento.
No es alcance del presente trabajo detallar la programación ni el código,
sino es presentar una nueva arquitectura de software para optimizar un
sistema de abastecimiento de medicinas entre SALOG y EsSalud.
Con respecto a las limitaciones, la implementación de esta nueva
arquitectura no incluye otra gestión que no sea Guías de Remisión,
Movimientos, Materiales, Órdenes de Compra y Proveedores.
1.4. Justificación
El proyecto se justifica porque se desea minimizar el riesgo de
desabastecimiento de medicinas en los centros hospitalarios de EsSalud y
tener una información precisa y actualizada.
Así mismo, al realizar la sincronización de data entre el sistema de SALOG
con SAP, la comunicación seguía un proceso muy largo y se procesaba
transacción por transacción lo cual generaba encolamiento de
transacciones. Cabe mencionar que las transacciones estaban ordenadas
por prioridad, lo cual indica que al momento de llegar una transacción en la
cola su ubicación podía ser reemplazada por otra de mayor prioridad.
Se optó por restructurar la arquitectura de la comunicación entre el sistema
de SALOG con SAP, obteniendo un proceso más corto y atendiendo varias
transacciones al mismo tiempo.
Es importante porque se agiliza el tiempo de comunicación con SAP para
tener información actualizada entre los dos sistemas.
14
CAPITULO 2
FUNDAMENTO TEÓRICO
15
2.1. Marco Teórico
2.1.1. Antecedentes del estudio
• 2012. Escasez de medicamentos: un problema mundial
complejo. Boletín de la Organización Mundial de Salud.
Recuperado de http://www.who.int/bulletin/volumes/90/3/11-
101303/es/
Comenta sobre la escasez de medicamentos, mostrando una lista
de medicinas principales faltantes en países de Europa, Asia y
América. Así mismo, explica las posibles causas diversas que los
organismos gubernamentales podrían remediar.
• 2017. Problemas de abastecimiento de medicamentos en el
sistema de salud peruano. Diario “La Gestión”. Recuperado de
http://blogs.gestion.pe/evidencia-para-la-gestion/2017/04/que-esta-
detras-de-los-problemas-de-abastecimiento-de-medicamentos-en-
el-sistema-de-salud-peruano.html
Explica las entidades vinculadas en los procesos de compra,
almacenamiento y distribución de medicamentos en Perú. Así
mismo, menciona las diferentes formas de adquisición de las
medicinas y los problemas que se generan en el flujo de adquisición
como por ejemplo demoras en las compras, cuando no existe la
postulación de proveedores y son declaratorias designadas como
“desierto” y faltas de almacenes especializados.
• Edison Francisco Muñoz Recuay, (2007). Tesis de grado:
Integrador de Sistemas Heredados, una solución para la
Integración de Información. Universidad Ricardo Palma, Lima –
Perú.
Se menciona que la integración de sistemas a avanzado
tecnológicamente desde la década de los 80 al 2007, el cual
recomienda generar comunicaciones fáciles y rápidas, mediante
sincronización de data en sistemas diferentes.
16
• Marcelo Alejandro Collao Huper, (2009). Tesis de maestría,
Controlador: un Framework de desarrollo para la integración de
sistema de software y cumplimiento de niveles de servicio.
Obtenido de:
http://www.tesis.uchile.cl/tesis/uchile/2009/collao_m/sources/collao
_m.pdf
En dicha tesis, se utiliza otro medio de integración de sistema
mediante Framework Controlador. Respecto a esta tesis debo
indicar que aporta conocimientos sobre el uso de otra herramienta
para poder integrar sistemas.
2.1.2. Metodología
▪ RUP
La metodología RUP, iniciales de Rational Unified Process o Proceso
Unificado Racional, es un producto comercial desarrollado y comercializado
por Rational Software que pertenece a la compañía IBM.
Se base en la elaboración de pasos a seguir para el desarrollo de proyectos
de software que precisa quién, cómo, cuándo y qué debe hacerse en el la
construcción del proyecto. La metodología RUP se ecuentra diseñada y
documentada en UML (Unified Modeling Language).
El Proceso Unificado está basado en tres conceptos: dirigidos mediante
casos de uso, centrado en la arquitectura, iterativo e incremental.
o El proceso Unificado mediante casos de uso
Una de las características es que RUP está dirigido por Casos de Uso que
es una técnica cuyo objetivo es obtener los diferentes requisitos del
sistema. Se puede definir un Caso de Uso a una funcionalidad del sistema.
Además de que los casos de uso sean una herramienta que se utiliza para
obtener los requisitos del sistema, dirigen también su diseño,
implementación y prueba.
17
o Proceso centrado en la Arquitectura
La arquitectura de un sistema es la estructura de sus partes, gracias a eso,
todos los involucrados podemos tener una visión más exacta.
A parte de hacer uso de los casos de uso para el proceso, se enfoca
también en el establecimiento de una arquitectura robusta que no sea
afectada a posibles futuros cambios.
Los Casos de Uso deben adaptarse a la arquitectura y la arquitectura debe
permitir la elaboración de todos los Casos de Uso solicitados, por tal motivo
los Casos de Uso y la arquitectura deben desarrollarse en paralelo.
La arquitectura se va volviendo más robusta a través de las fases de RUP.
o Proceso iterativo e incremental
La estrategia que se plantea en RUP es tener un proceso iterativo e
incremental en donde el trabajo se descompone en partes más pequeñas
o también entendidas como mini proyectos. Cada mini proyecto es una
iteración el cual produce una progresión o crecimiento del producto.
Una iteración atraviesa por los siguientes flujos:
- Requisitos
- Análisis
- Diseño
- Implementación
- Pruebas
18
Ilustración 2: Iteración en RUP
Como se muestra en la ilustración, el proceso iterativo e incremental
consiste en una sucesión de iteraciones hasta finalizar con la versión actual
del producto.
o Fases de RUP
La metodología RUP divide el proceso en cuatro fases, donde se logra
realizar varias iteraciones según sea el proyecto.
Inicio
En la fase de Inicio se da por definir tanto el modelo del negocio como el
alcance del proyecto, también se logra identificar los riesgos relacionados
al proyecto, se reconocen la totalidad de actores posibles y casos de uso y
se diseñan los más importantes. De igual manera, se tiende a elaborar un
plan de negocio para determinar que recursos deben ser asignados al
proyecto.
Objetivos de la fase de Inicio:
- Establecer el ámbito o entorno del proyecto, así como también sus
límites.
- Identificar los Casos de Uso graves que pudieran existir en
sistema.
19
- Mostrar en general una arquitectura posible para los escenarios
principales.
- Calcular el valor aproximado del costo en recursos y el tiempo en
que empleará el proyecto.
- Reconocer los posibles riesgos.
Elaboración
En la fase de elaboración se tiene como objetivo analizar el problema,
establecer las bases de la arquitectura, desarrollar el plan del proyecto y
deshacer los riesgos de mayor importancia.
Se diseña la solución preliminar construyendo un prototipo o modelo de la
arquitectura, que debe crecer con iteraciones constantes hasta alcanzar el
sistema final.
Objetivos de esta fase:
- Definir, validar y cimentar la arquitectura.
- Crear un plan fiable para lo que concierne a la fase de construcción.
- La arquitectura propuesta debe demostrar que puede soportar la
visión con un coste y tiempo justo y prudente.
Construcción
El principal objetivo de esta fase es culminar con la funcionalidad del
sistema. Todos los componentes, características y requisitos deben ser
implementados, integrados y testeados en su totalidad con la finalidad de
obtener una versión buena o aceptable del producto.
Los objetivos incluyen:
- Reducir los costes de desarrollo realizando la optimización de
recursos.
- Realizar versiones funcionales del producto.
20
Los resultados de la fase de construcción deben ser:
- Modelos completos (casos de uso, análisis, diseño, despliegue e
implementación).
- Riesgos reducidos.
- Manual inicial de usuario, el cual debe estar bien detallado.
- Prototipo operacional.
Transición
La finalidad de esta fase es garantizar que el software esté accesible para
los usuarios, poniéndolo en mano de los usuarios finales.
Otros objetivos:
- Capacitar a los usuarios brindando soporte necesario en el manejo
del producto.
- Conseguir que el usuario sea independiente con el sistema.
- Conseguir que el producto final haga cumplimento de los requisitos
ansiados, que funcione y que de una gran satisfacción al usuario.
Ilustración 3: Fases del Método RUP
21
o Estructura de RUP
El proceso puede ser descrito en dos dimensiones:
Eje horizontal
Representa el tiempo y muestra el aspecto dinámico del proceso expresado
en términos de fases, iteraciones.
Eje Vertical
Representa el aspecto estático del proceso, en términos de actividades,
flujos de trabajo.
Ilustración 4: Estructura de RUP
22
▪ SCRUM
Las organizaciones intentan alcanzar grandes objetivos de negocio a través
de los sistemas a la medida, esto representan desafíos comunes que se
pueden superar si se aplica una metodología rigurosa. Una de estas
metodologías es SCRUM.
SCRUM está orientado al trabajo en equipo entre cliente y proveedor,
donde sus integrantes colaboran con el fin de avanzar gradualmente y
lograr la entrega en un producto de calidad en tiempo y costos planeados.
Está basado en entregas parciales del producto final. El proyecto se divide
en Sprint que es cada una de las fases del proyecto donde se presenta los
avances al cliente, el cliente prueba el producto, lo aprueba o sugiere
cambios.
El cliente conoce la etapa en la que se encuentra su proyecto y se redefinen
los requerimientos.
Una vez finalizado los Sprints necesarios se hace entrega del producto
final.
Aplicar la metodología SCRUM significa realizar los proyectos de una mejor
manera, en menor tiempo y costo posible.
Ilustración 5: SCRUM
23
Véase la siguiente imagen sobre la Metodología SCRUM:
Ilustración 6: Metodología SCRUM
24
▪ Cuadro comparativo de Metodologías
Tabla 1: Comparación de Metodologías
Se eligió la metodología SCRUM debido a que se presenta avances del
proyecto al cliente, el cual da su punto de vista y se obtiene un feedback,
lo que permite mejorar la comunicación entre cliente y proveedor y de que
se construya un software el cual será más adaptivo a la necesidad del
cliente.
25
2.1.3. Lenguaje de Programación
▪ JAVA
Es un lenguaje de programación el cual está orientado a objetos, fue
desarrollado por Sun Microsystems. Es un lenguaje que proviene desde un
principio del lenguaje C, por tal motivo, las reglas de sintaxis de ambos
lenguajes se asemejan bastante.
Se dice que es un lenguaje orientado a objetos debido a que permite
implementar el uso de clases, objetos, encapsulación, herencia, entre otros,
lo que reduce la complejidad de la programación.
Es un lenguaje independiente de la plataforma, puede ejecutarse en
computadoras con sistemas operativos diferentes (Windows, Linux) lo cual
facilita el trabajo para un desarrollador.
El lenguaje de java se utiliza en dispositivos móviles, también permite crear
aplicaciones applets que se adhieren en código HTML de una página web
con la capacidad de aplicar acciones complejas como, por ejemplo: realizar
animación de imágenes, hacer presentación de menús y cuadros de
diálogos, establecer conexiones de red, entre otros.
▪ PHP
Es el acrónimo de Hypertext Preproces. Es un lenguaje de programación
de código abierto, de uso libre y gratuito muy empleado en la programación
web y también utilizado en HTML lo que significa que un código HTML se
puede incluir código PHP, muchas páginas web están creadas en este
lenguaje.
Así mismo, es un lenguaje gratuito, independiente de plataforma, rapidez y
seguridad. Antes de que la página sea enviada a través del internet al
cliente, el código es ejecutado en el servidor web, estas páginas pueden
acceder a base de datos, conexiones en red y otras tareas que visualizará
el cliente final. Como resultado final el cliente recibe una página con código
HTML producto de la ejecución de PHP, la cual es compatible con todos
los navegadores.
26
Es independiente de plataforma, compatible con cualquier sistema y
permite trasladar el sitio desarrollado a otro sistema sin dificultad. Posee
una extensa librería de funciones las cuales ayudan a realizar muchos tipos
de aplicaciones web y realizar varios tipos de proceso de información
necesitados en las aplicaciones, permiten realizar de una manera sencilla
tareas habituales.
De igual manera, son compatibles con bases de datos más conocidas como
MySQL, ORACLE, ODBC, entre otras.
▪ Cuadro comparativo de Lenguajes de Programación
Debido a que nuestro proyecto se basa en la comunicación del sistema de
SALOG implementado en los centros hospitalarios de EsSalud con el
sistema SAP. Se optó por la programación en Java debido a que es un
lenguaje orientado a objetos lo cual representa una programación con
normas definidas de forma precisa que brinda una comprensión más
sencilla. Así mismo, es un lenguaje que cuenta con librerías que permiten
conectarse con el sistema SAP.
Características JAVA PHP
Programación código
abierto
Si Si
Programación
Orientada a Objetos
Si No
Multiplataforma Si SI
Librerías conexión con
SAP
Si No
Compatibilidad con
BD
MySQL, ORACLE MySQL, ORACLE
Tabla 2: Comparación de Lenguajes de Programación
27
2.1.4. Gestor de Base de Datos
▪ MySQL
Es un sistema de gestión de base de datos relacional, su código es abierto
y su lenguaje se encuentra basado en el Lenguaje de Consulta
Estructurado (SQL). Una base de datos relacional almacena los datos en
tablas diferentes lo que permite que la consulta de data sea más veloz y
flexible. Las tablas son unidas al realizar relaciones que hacen posible
combinar datos de diferentes tablas cuando se realizan las consultas en la
base de datos.
MySQL es bastante utilizado en base de datos sobre todo para aplicaciones
web, en especial en paquete LAMP que es un conjunto de softwares de
código abierto que se instala en unión para preparar un servidor con el fin
de alojar sitios y aplicaciones web dinámicas (Sistema Operativo Linux,
Servidor Apache, Base de Datos MySQL, Lenguaje de Programación PHP),
también existen otras opciones como MAMP y WAMP. Así mismo, MySQL
permite interacción con los lenguajes más usados como PHP, java, entre
otros.
Características:
- MySQL es un sistema de Gestión de Base de datos desarrollado
en el lenguaje C y C++.
- Para realizar consultas a la base de datos se realiza mediante el
lenguaje SQL.
- Mantiene gran cantidad de tipo de datos para las columnas.
- Puede trabajar en múltiples plataformas Linux, MAC, Windows
entre otras.
- Velocidad al realizar las operaciones.
- Facilidad de configuración e instalación.
28
▪ ORACLE
Es un sistema de gestión de base de datos relacional hecho por Oracle
Corporation. Es una herramienta cliente/servidor muy potente para la
gestión de base de datos, debido a su gran potencia y su elevado precio
hace a que generalmente solo lo adquieran empresas muy grandes o
multinacionales.
Así mismo en el desarrollo de páginas web, ORACLE no está tan expandido
como otras bases de datos como MySQL. SAL Server, entre otras debido
a su alto precio.
ORACLE usa el lenguaje PL/SQL cuyo lenguaje se reconoce que es
bastante potente para gestionar la base de datos.
Características:
- Modelo de base de datos objeto-relacional.
- Multiplataforma
- Se puede ejecutar en varios sistemas operativos: Linux, MAC,
Windows, entre otros.
▪ Cuadro comparativo de Gestor de BD
Tabla 3: Comparación de Gestor de BD
29
Para la elaboración de este proyecto se trabajó con el gestor de base de
datos ORACLE debido a que la empresa SALOG desde un principio ya
contaba con el servicio de éste y que además ORACLE posee un soporte
por lo cual se externaliza las incidencias.
2.2. Marco conceptual
Definición de conceptos
• ORACLE: Gestionador de Base de Datos.
• Job: Tareas que se ejecutan en una BD en una determinada fecha
y hora.
• MOM: Es un tipo de middleware orientado a mensajes. Este tipo de
middleware facilita la comunicación mediante intercambio de
mensajes y la entrega de mensajes lo realiza mediante colas.
• JMS: Implementación del modelo MOM en java.
• Productor: Aplicación que envía un mensaje
• Consumidor: Componente receptor que recupera el mensaje.
• ActiveMQ: Servidor gratuito de colas. Gestiona los mensajes en
cola.
• Archivo Jar: A través de los ficheros Jar (Java ARchives) se puede
recopilar varios ficheros en un único fichero, son almacenados en un
formato comprimido para que no ocupen mucho espacio.
• RUP: Proceso Unificado Racional, es una metodología para
desarrollar proyectos de software.
• SCRUM: Metodología Agil en donde se ejecutan un conjunto de
buenas prácticas y se trabaja en equipo, de esta forma se obtiene
un resultado optimo del proyecto
30
2.3. Marco Metodológico
Para la elaboración del presente proyecto, se optó por la metodología
SCRUM comparada con otra metodología en el punto 2.1.2 del presente
informe. Por tal motivo en este punto, se enfocará a más profundidad.
2.3.1. Metodología SCRUM
SCRUM es una metodología flexible y ágil para realizar la gestión y el
desarrollo de software. En este proceso se aplican de manera constante un
conjunto de buenas prácticas para realizar un trabajo colaborativo, en
equipo y de esta manera poder conseguir el mejor resultado posible de un
proyecto.
Con esta metodología el cliente ve crecer su proyecto gracias a las
iteraciones recurrentes, le permite también de reformar los objetivos del
negocio en cualquier momento.
En Scrum se elaboran tanto entregas parciales como regulares del
producto final.
2.3.2. Beneficios
• Entrega mensual o quincenal de resultados
• Flexibilidad a cambios
La metodología está diseñada para acoplarse a los diferentes
cambios que puedan surgir de los requerimientos que serán del
interés de las necesidades del cliente.
• Reducción del Time to Market
El cliente puede hacer uso de las funcionalidades más relevantes del
proyecto antes de que este esté finalizado.
• Mayor calidad del software
Gracias a las iteraciones donde se obtiene versiones funcionales se
obtiene un producto de mayor calidad.
• Mayor productividad
El equipo de trabajo es autónomo, ellos mismos eligen la forma de
organizarse. Son autónomos.
• Reducción de riesgos
31
2.3.3. Roles de Scrum
▪ Product Owner
Es la persona donde cae la responsabilidad del éxito del producto.
Sus responsabilidades son:
- Definir la visión del producto, dónde se está dirigiendo el
equipo de desarrollo.
- Gestionar las expectativas de los stakeholders.
- Juntar los requerimientos.
- Definir y tener conocimiento sobre las características
funcionales del producto.
- Generar y mantener el plan de entregas (reléase plan)
- Diagnosticas las importancias de cada una de las
características (prioridades).
- Cambiar las prioridades de las características según el
proyecto va avanzando.
- Poder Aceptar y también descartar el producto desarrollado
durante el Sprint y proveer feedback para su crecimiento.
- Ser partícipe de la revisión del Sprint en compañía de los
miembros que conforma el equipo
▪ Equipo de Desarrollo
El equipo de desarrollo se encuentra formado por el personal
imprescindible para la construcción o desarrollo del producto.
El equipo de desarrollo se encarga de su propia organización, no
existe un líder. El equipo es quien designa como se realizará el
trabajo y como resolverá si en caso se presentes problemas.
▪ Scrum Master
Es el líder del equipo en la gestión de proyectos. Hace cumplir a tos
los participantes del proyecto con los procesos de Scrum.
32
2.3.4. Elementos de Scrum
El proceso de Scrum contiene algunos elementos formales que de tal
manera se pueda avanzar un proyecto de desarrollo:
Product Backlog
Es uno de los elementos más importante de Scrum, el backlog es una lista
de ítems o características del producto a construir, sostenible y cuyas
prioridades es hecha por el Product Owner.
Es importante definir la priorización de cada característica ya que será el
orden en que el equipo de trabajo transformará en un producto funcional
terminado.
Sprint Backlog
Es un conjunto de tareas las cuales las realiza el equipo en la reunión de
planificación de la iteración.
El Sprint Backlog es un paquete de PBIs (ítems del producto) que fueron
elegidos con la finalidad de trabajarlos durante un Sprint, en unión con las
tareas que el equipo de desarrollo ha determinado que debe realizar para
poder elaborar un incremento funcional entregable al finalizar el Sprint.
Ilustración 7: Sprint Backlog
33
Increment
Es un avance funcional potencialmente entregable, debe ser el resultado
de cada Sprint.
Incremento funcional
Se dice que es un incremento o avance funcional debido a que es
una característica funcional modificada o recientemente elaborada
de un producto que está construyéndose de una forma evolutiva.
Potencialmente entregable
Se dice que es potencialmente entregable porque se realiza una
validación y verificación de cada una de las características del
producto, en donde se determina que puede ser entregada al usuario
si así lo estipula.
2.3.5. Eventos de Scrum
Sprint
Sprint son las iteraciones que se realizan. Scrum es un proceso de
desarrollo incremental e iterativo eso quiere decir que el producto se
elabora teniendo avances funcionales presentados en lapsos cortos de
tiempo para obtener a menudo y hacer uso de los feedbacks.
Los Sprints duran aproximadamente entre 1 a 4 semanas, siendo 2 o 3
semanas lo más habitual. Se recomienda establecer la duración de los
Sprint al comenzar el proyecto y mantenerlo constante durante el desarrollo
del producto.
Sprint Planning (Planificacion de Sprint)
Al iniciar cada Sprint se habitúa realizar una reunión de planificación del
Sprint donde el equipo de desarrollo y Product Owner generarán acuerdos
y compromisos respecto al alcance del Sprint.
Dicha reunión de planificación está compuesta en dos partes, la primera
parte estratégica y orientada en el “qué” y la segunda parte táctica enfocada
en el “cómo”.
34
• Primera parte de la reunión (reunión de 4 horas como máximo)
- El cliente hace presente al equipo los requisitos del proyecto
a realizarse, establece nombre a la meta de la iteración y
propone requisitos de mayor prioridad a desarrollarse.
- El equipo analiza la lista, esclarece al cliente las dudas y
selecciona los objetivos más importantes que se compromete
a completar en la iteración.
• Segunda parte de la reunión (reunión de 4 horas como máximo)
El equipo planifica la iteración, elabora la táctica que le permitirá
conseguir el mejor resultado, la forma en la que llevará adelante el
trabajo.
Scrum Diario
A la reunión diaria asiste el equipo de trabajo y el ScrumMaster. Se realiza
las siguientes peguntas que se responderán por turnos:
1. ¿Desde la última reunión que he realizado o avanzado hasta el día
de hoy?
2. ¿Desde ahora hasta que haya la próxima reunión diaria, cuáles
serán las tareas en las que trabajaré?
3. ¿Qué obstáculos o dificultades tengo?
Cabe resaltar que esta reunión es enriquecedora ya que la comunicación y
el diálogo entre los integrantes del equipo de desarrollo se intensifica.
Al realizar la primera pregunta, se verifica si los integrantes del equipo de
desarrollo han cumplido con sus compromisos respectivos.
En la segunda pregunta, se da a conocer los nuevos compromisos
Finalmente, la tercera pregunta da a conocer los obstáculos que se les ha
presentado a los integrantes del equipo de desarrollo que serán resueltos
posteriormente y será responsabilidad del Scrum Master de que sean
resueltas lo más antes posible.
35
2.3.6. Roles de usuario
Para analizar el sistema, se debe identificar los usuarios posibles con el
que el sistema poseerá.
2.3.7. Historias de Usuario
En los proyectos de desarrollo de software, la comunicación entre el cliente
y el desarrollador solía hacerse mediante documentación más conocida
como especificaciones funcionales que causaban malos entendidos y
muchas veces el software elaborado no era con lo que se esperaba.
Una de la razón por la cual las especificaciones funcionales transmitidas
como una forma de comunicación no conlleva a resultados esperado o
agradables es debido a que no existe una comunicación en persona. Las
historias de usuario son especificaciones funcionales que incitan a un
dialogo para que el detalle no sea un remplazo sino más bien una
consecuencia.
Una historia de Usuario lo integran 3 elementos, llamados como “las tres
Cs”.
▪ Card
Toda historia de usuario debe ser escrita en una ficha pequeña, si
no alcanzara, se debería compartir la información presencialmente.
▪ Conversación
Toda historia debe ser conversada con el Product Owner. Una
comunicación presencial que permita intercambiar tanto opiniones,
pensamientos y sentimientos (muy a parte de la información).
▪ Confirmación
Toda historia de usuario debe estar muy bien explicada de tal
manera que el equipo de desarrollo comprenda qué es lo ha de
desarrollar.
Como (rol) Necesito (funcionalidad) Para (beneficio)
36
Los beneficios que trae este modo de redacción son:
- Ponerse en el lugar del usuario, la persona quien lee una
determinada historia de usuario comprende mejor la
necesidad del usuario.
- Ayuda a priorizar las funcionalidades.
37
CAPÍTULO 3
DESARROLLO DE LA SOLUCIÓN
38
3.1. Breve descripción de la Solución
La nueva arquitectura se basa en la utilización de un archivo JAR al cual se
nombró IRFC, se encuentra basado en lenguaje JAVA que es ejecutado
mediante tareas programadas. Este archivo JAR se encarga de procesar
las transacciones que se sincronizan del sistema de SALOG a SAP cuando
se requiere enviar datos de las Guías de Remisión y Movimientos. Así
mismo, procesa la información que se encuentra en el sistema SAP y debe
sincronizarse al sistema SALOG como son el caso de Materiales, órdenes
de compra y proveedores con la finalidad de que SALOG tenga una base
de datos actualizada.
El proceso de transacciones se realiza de la siguiente manera:
Tareas Programadas
• ProcesarCola
•ReprocesarCola
• (Se ejecuta cada minuto)
Archivos .BAT
• PROCESAR_COLA.BAT
•REPROCESAR_COLA.BAT
JAR IRFC
• Procesa transacciones mediante hilos.
39
La nueva arquitectura es la siguiente:
Ilustración 8: Diagrama de propuesta de solución
1. Cuando se ejecuta la función PROCESAR_COLA del Jar IRFC,
consulta la tabla de colas en BD ORACLE (ERP_CTR_QUEUE), la
cantidad de transacciones que tome va a depender de la cantidad
de hilos que se configuro en el Jar IRFC.
2. Recibida la lista de transacciones en cola, las almacena en la tabla
ERP_CTR_TRANSACT con estado “procesando”.
3. Realiza Transacción SAP mediante el parámetro jco quien realiza la
conexión con SAP y envía ciertos parámetros.
40
Acorde a la respuesta de SAP se realiza lo siguiente:
Éxito:
Cuando se logra sincronizar la data entre el sistema SALOG y SAP.
Se actualiza el estado de la transacción a “exitoso” en la tabla
ERP_CTR_TRANSACT, la transacción desaparece de la tabla
ERP_CTR_QUEUE y va a la tabla de historia de colas ERP_CTR_HIST.
Error:
Cuando no se envió todos los parámetros necesarios de la transacción a
procesar.
Se actualiza el estado de la transacción a “Error” en la tabla
ERP_CTR_TRANSACT. La transacción desaparece de la tabla
ERP_CTR_QUEUE y va a la tabla de errores ERP_CTR_ERROR, esta
transacción se puede volver a reprocesar mediante interfaz volviendo a la
tabla ERP_CTR_QUEUE y tomándola como nueva transacción.
Reproceso:
Se actualiza el estado de la transacción a “Reproceso” en la tabla
ERP_CTR_TRANSACT para que sea procesado por la función
REPROCESAR_COLA del Jar IRFC.
Nota: la aplicación usa hilos para procesar varias transacciones a la vez.
41
3.2. Diagrama de flujo
Ilustración 9: Flujo de Proceso de Cola
3.3. Requerimientos Funcionales
A continuación, se muestra el detalle de los requerimientos funcionales:
ID Detalle Proceso
ADT0001 Establecer conexión bajo una
configuración determinada
Enviar Información
ADT0002 Preparar información de
Guías de Remisión
Enviar Información
ADT0003 Preparar información de
Movimientos
Enviar Información
ADT0004 Enviar información de Guías
de Remisión
Enviar Información
ADT0005 Enviar información de
Movimientos
Enviar Información
ADT0006 Validar información de Guía
de Remisión
Enviar Información
ADT0007 Validar información de
Movimientos
Enviar Información
ADT0008 Establecer conexión bajo una
configuración determinada
Recibir Información
ADT0009 Definir información de
Materiales por recibir
Recibir Información
ADT0010 Definir Información de
Órdenes de Compra por
recibir
Recibir Información
ADT0011 Definir Información de
Proveedores por recibir
Recibir Información
ADT0012 Solicitar Información de
Material
Recibir Información
ADT0013 Solicitar Información de
Orden de Compra
Recibir Información
43
ADT0014 Solicitar Información de
Proveedor
Recibir Información
ADT0015 Integrar Información de
Material
Recibir Información
ADT0016 Integrar Información de Orden
de Compra
Recibir Información
ADT0017 Integrar Información de
Proveedor
Recibir Información
44
3.4. Roles de usuario
▪ Doctores
Regular manejo del sistema con bajo conocimiento del dominio del
problema. Este usuario tiene un bajo nivel relacionado a la
experiencia en el uso de computadoras y posee experiencia de nivel
regular en el uso del sistema en particular.
La responsabilidad de este usuario constará de realizar recetas a los
pacientes derivándolos a farmacia para que los recojan.
▪ Analistas
Usuario que tiene nivel alto de experiencia en el uso del sistema, con
conocimiento bajo del problema. Posee un alto nivel en el manejo de
computadoras.
La responsabilidad constará de realizar seguimientos de los stocks
de los medicamentos o materiales para cada centro hospitalario a su
cargo.
▪ Técnicos en Farmacia
Usuario cuenta con un intenso uso del sistema, conoce muy bien el
problema. Posee un nivel regular en el uso de computadoras.
Su responsabilidad constará de despachar los medicamentos que
contienen las recetas de los pacientes. Así mismo, verificar en el
sistema el stock de los medicamentos y materiales médicos.
▪ Personal de Almacén
Usuario que utiliza con mucha frecuencia el sistema, tiene
conocimiento alto del problema. Posee un nivel mayor en el manejo
de computadoras y por último, posee alto nivel de experiencia eon
el uso del sistema.
Su responsabilidad será de generar guías de remisión para el envío
de medicamentos y materiales médicos a los diferentes centros
hospitalarios de las tres redes de EsSalud Rebagliati, Almenara y
Sabogal a nivel de Lima y Callao.
45
▪ Mesa de ayuda
Realiza un intenso uso del sistema, posee un alto conocimiento
respecto al dominio del problema. Tiene un nivel alto de experiencia
en el manejo de computadoras, así como en el uso del sistema.
Su responsabilidad será dar soporte con respecto al sistema a los
usuarios de los centros hospitalarios y del almacén central.
3.5. Visual Story Mapping
3.5.1. Identificación de los Procesos de Negocio
Se identificaron los siguientes procesos:
▪ Enviar Información
▪ Recibir Información
3.5.2. Identificación de Funcionalidades
Funcionalidades que deberá contar el sistema. De acuerdo a los
procesos de negocio, se han identificado las siguientes
funcionalidades:
▪ ENVIAR INFORMACION
o Establecer conexión con SAP
- Establecer conexión bajo una configuración
determinada
o Preparar información a enviar
- Preparar información de Guías de Remisión
- Preparar información de Movimientos
o Enviar información
- Enviar información de Guías de Remisión
- Enviar información de Movimientos
o Validar información enviada
- Validar información de Guías de Remisión
- Validar información de Movimientos
46
▪ RECIBIR INFORMACION
o Validar conexión con SAP
- Establecer conexión bajo una configuración
determinada
o Definir información por recibir
- Definir información de Materiales por recibir
- Definir información de Órdenes de Compra por recibir
o Solicitar información definida
- Solicitar información de Material
- Solicitar información de Órdenes de Compra
- Solicitar información de Proveedores
o Validar información recibida (Integración)
- Integrar información de Material
- Integrar información de Órdenes de Compra
- Integrar información de Proveedores
A continuación, se muestra el Visual Story Mapping:
Ilustración 10:Visual Story Mapping
Procesos de
Negocio
Establecer
conexión con
SAP
Preparar
informacion a
enviar
Enviar
Informacion
Validar
informacion
enviada
Validar conexión
con SAP
Definir
informacion por
recibir
Solicitar
informacion
definida
Validar
informacion
recibida
(Integracion)
Actividades
Release 1
Establecer
conexión bajo
una
configuracion
determinada
Preparar
informacion de
Guias de
Remision
Enviar
informacion de
Guias de
Remision
Validar
informacion de
Guia de
Remision
Establecer
conexión bajo
una
configuracion
determinada
Definir
informacion de
Materiales por
recibir
Solicitar
informacion de
Material
Integrar
informacion de
Material
Release 2
Preparar
informacion de
Movimientos
Enviar
informacion de
Movimientos
Validar
informacion de
Movimientos
Definir
informacion de
Ordenes de
Compra por
recibir
Solicitar
informacion de
Orden de
Compra
Integrar
informacion de
Orden de
Compra
Release 3
Definir
informacion de
Proveedores por
recibir
Solicitar
informacion de
Proveedor
Integrar
Informacion de
Proveedor
RECIBIR INFORMACIONENVIAR INFORMACION
Herramientas
o Historias de
Usuario
3.6. Identificación de Entregas
La identificación de entregas se realiza mediante un Producto
Mínimo Viable (MVP).
3.6.1. MVP (Entrega 1)
Entrega 1 – Objetivo: Establecer conexión y sincronizar data
de Guías de Remisión y de Materiales
▪ ENVIAR INFORMACION
o Establecer conexión con SAP
- Establecer conexión bajo una configuración
determinada.
o Preparar información a enviar
- Preparar información de Guías de Remisión
o Enviar información
- Enviar información de Guías de Remisión
o Validar información enviada
- Validar información de Guía de Remisión
▪ RECIBIR INFORMACION
o Definir información por recibir
- Definir información de Materiales por recibir.
o Solicitar información definida
- Solicitar Información de Material
o Validar información recibida
- Integrar Información de Material
49
3.6.2. MVP (Entrega 2)
Entrega 2 – Objetivo: Sincronizar información de
Movimientos y Órdenes de Compra
▪ ENVIAR INFORMACION
o Preparar información a enviar
- Preparar información de Movimientos
o Enviar información
- Enviar información de Movimientos
o Validar información enviada
- Validar información de Movimientos
▪ RECIBIR INFORMACION
o Definir información por recibir
- Definir información de Órdenes de Compra
o Solicitar información definida
- Solicitar Información de Órdenes de Compra
o Validar información recibida
- Integrar Información de Órdenes de Compra
3.6.3. MVP (Entrega 3)
Entrega 3 – Objetivo: Sincronizar información de
Proveedores
▪ RECIBIR INFORMACION
o Definir información por recibir
- Definir Información de Proveedores por recibir
o Solicitar información definida
- Solicitar Información de Proveedor
o Validar información recibida
- Integrar Información de Proveedor
50
3.7. Historias de Usuarios
Se presenta a continuación las historias de usuarios para la Entrega 1:
Entrega 1 - Establecer conexión y sincronizar data de Guías de
Remisión y de Materiales
Pri Como Necesito Para Criterios de
Aceptación
1 Analista Establecer
conexión bajo
una
configuración
determinada
Asegurar el
correcto envío y
recepción de
información con
EsSalud
La conexión con
SAP debe ser
parametrizada y
configurable.
Si la conexión con
SAP no es exitosa
no se debe enviar
ni recibir
información.
2 Analista Preparar
información de
Guías de
Remisión
Enviar
información de
guías de remisión
a SAP
La información
enviada debe
poder corroborarse
en el sistema SAP
3 Analista Enviar
información de
Guías de
Remisión
Informar a SAP
de los
medicamentos
que se enviarán a
los hospitales
Se debe enviar
información de la
guía y del detalle
de materiales a
trasladar.
4 Analista Validar
información de
Guía de
Remisión
Asegurar que la
información llegó
a SAP
exitosamente
Se debe manejar
estados acordes a
la respuesta del
sistema SAP
5 Analista Definir
información de
Indicar al sistema
SAP los
Se debe
determinar el
51
Materiales por
recibir.
materiales que se
solicitaran
rango de
materiales y el
rango de fechas
para consultar
6 Analista Solicitar
Información de
Material
Conocer la
información
modificada en
SAP respecto a
los materiales
Se debe
almacenar la
información de los
materiales en un
estado temporal
previo a la
integración
7 Analista Integrar
Información de
Material
Mantener el
catálogo de
materiales
actualizado
Se debe actualizar
el catálogo de
materiales en el
sistema local
52
Historias de usuario para la Entrega 2:
Entrega 2 - Sincronizar información de Movimientos y Órdenes de
Compra
Pri Como Necesito Para Criterios de
Aceptación
8 Analista Preparar
información de
Movimientos
Definir el
movimiento en
almacén para
informar al
sistema SAP
Se debe indicar el
tipo de movimiento
(ingreso, salida)
Se debe indicar
los materiales que
se están moviendo
9 Analista Enviar
información de
Movimientos
Informar al
sistema SAP de
los movimientos
en el Almacén
Se debe poder
corroborar la
información de
movimientos en el
sistema SAP
10 Analista Validar
información de
Movimientos
Asegurar que los
movimientos
fueron enviados a
SAP
correctamente
Se debe manejar
estados acordes a
la respuesta del
sistema SAP
11 Analista Definir
información de
Órdenes de
Compra
Indicar al sistema
SAP las órdenes
de compra que se
solicitaran
Se debe indicar
información de la
orden de compra y
los materiales
involucrados en
esta.
12 Analista Solicitar
Información de
Órdenes de
Compra
Conocer las
nuevas órdenes
de compra
Se debe
almacenar
información de las
órdenes de
53
emitidas por
Essalud
compra previa a
su integración
13 Analista Integrar
Información de
Órdenes de
Compra
Mantener las
ordenes de
compras
actualizadas en el
sistema local
Se debe actualizar
el catálogo de
órdenes de
compra en el
sistema local
Historias de usuario para la Entrega 3:
Entrega 3 - Sincronizar información de Proveedores
Pri Como Necesito Para Criterios de
Aceptación
14 Analista Definir
Información de
Proveedores
por recibir
Indicar al sistema
SAP los
proveedores que
se van a requerir
Se debe indicar el
código de
proveedor
15 Analista Solicitar
Información de
Proveedor
Conocer
información
detallada de los
proveedores
Se debe
almacenar la
información del
proveedor previa a
su integración
16 Analista Integrar
Información de
Proveedor
Mantener
actualizado el
catálogo de
proveedores de
EsSalud
Se debe actualizar
el catálogo de
proveedores en el
sistema local
54
3.8. Plan de Entregas (Release Plan)
En cuanto al plan de entregas, se presentan las historias de Usuario,
haciendo uso de Fibonacci y considerando una velocidad de Iteración de
15 puntos de historia con una duración de dos semanas:
Entrega 1 - Establecer conexión y sincronizar data de Guías de
Remisión y de Materiales
Pri Como Necesito Para Estim
Sprint 1
1 Analista Establecer
conexión bajo
una
configuración
determinada
Asegurar el correcto envío y
recepción de información
con EsSalud.
8
Sprint 2
2 Analista Preparar
información de
Guías de
Remisión
Enviar información de guías
de remisión a SAP.
3
3 Analista Enviar
información de
Guías de
Remisión
Informar a SAP de los
medicamentos que se
enviarán a los hospitales.
5
4 Analista Validar
información de
Guía de
Remisión
Asegurar que la información
llegó a SAP exitosamente.
5
Sprint 3
5 Analista Definir
información de
Materiales por
recibir.
Indicar al sistema SAP los
materiales que se solicitarán.
3
55
6 Analista Solicitar
Información de
Material
Conocer la información
modificada en SAP respecto
a los materiales.
3
7 Analista Integrar
Información de
Material
Mantener el catálogo de
materiales actualizado.
5
Entrega 2 - Sincronizar información de Movimientos y Órdenes de
Compra
Pri Como Necesito Para Estim
Sprint 4
8 Analista Preparar
información
de
Movimientos
Definir el
movimiento en
almacén para
informar al sistema
SAP.
3
9 Analista Enviar
información
de
Movimientos
Informar al sistema
SAP de los
movimientos en el
Almacén.
5
10 Analista Validar
información
de
Movimientos
Asegurar que los
movimientos fueron
enviados a SAP
correctamente.
5
Sprint 5
11 Analista Definir
información
de Órdenes
de Compra
Indicar al sistema
SAP las órdenes de
compra que se
solicitarán.
3
56
Entrega 3 - Sincronizar información de Proveedores
Pri Como Necesito Para Estim
Sprint 6
14 Analista Definir
Información
de
Proveedores
por recibir
Indicar al sistema SAP
los proveedores que se
van a requerir
5
15 Analista Solicitar
Información
de
Proveedor
Conocer información
detallada de los
proveedores.
5
16 Analista Integrar
Información
de
Proveedor
Mantener actualizado
el catálogo de los
proveedores de
EsSalud.
8
12 Analista Solicitar
Información
de Órdenes
de Compra
Cnocer las nuevas
ordes de compra
emitidas por
EsSalud.
5
13 Analista Integrar
Información
de Órdenes
de Compra
Mantener las
ordenes de
compras
actualizadas en el
sistema local.
5
57
3.9. Cronograma
Se presenta a continuación el cronograma de las entregas relacionadas al
proyecto:
Etapa Duración Desde Hasta
Incepción 2 semanas 02-mayo-2016 13-mayo-2016
Entrega 1
Sprint 1 2 semanas 16-mayo-2016 27-mayo-2016
Sprint 2 2 semanas 30-mayo-2016 10-junio-2016
Sprint 3 2 semanas 13-junio-2016 24-junio-2016
Entrega 2
Sprint 4 2 semanas 27-junio-2016 08-julio-2016
Sprint 5 2 semanas 11-julio-2016 22-julio-2016
Entrega 3
Sprint 6 2 semanas 25-julio-2016 05-ago-2016
58
3.10. Base de datos
Se muestra las tablas involucradas en el proyecto:
Ilustración 11: Base de datos del proyecto
59
CAPITULO 4
RESULTADOS
60
4.1. Resultados
4.1.1. Resultados
a) Objetivo Específico 1: “Diseñar una nueva arquitectura de
comunicación entre el sistema de SALOG y SAP”.
Ayudó a mejorar la comunicación entre ambos sistemas,
optimizando el tiempo de procesamiento de transacciones,
minimizando los pasos existentes en tal proceso y mejorando la
sincronización de data de un sistema a otro.
En la antigua arquitectura, la comunicación entre ambos
sistemas se realizaba mediante un productor que entregaba las
transacciones a un consumidor mediante el uso de colas,
procedimiento que se realizaba en seis pasos. Con la nueva
arquitectura se minimizaron y se simplificaron los pasos a tres.
Comparación de las arquitecturas del sistema
Antigua Arquitectura Nueva Arquitectura
Pasos 6 3
Tiempo 500 a 800 transacciones por día
800 a 1200 transacciones por día
Servidor Web Apache Tomcat No
Servicio de Colas
Active MQ No
Lenguaje Java Java
Encolamiento Alto Bajo
Quejas Muchas Muy poco
Procesamiento en paralelo
No, (Uno por uno) Varias al mismo tiempo (hasta 8 a la
vez)
Tabla 4: Comparación de arquitecturas del sistema
Nota:
En el anexo 1, se puede visualizar el modelo de la antigua
arquitectura y en la ilustración 6 del capítulo 3 se puede
observar la Nueva Arquitectura.
61
b) Objetivo Especifico 2: “Optimizar el tiempo de la sincronización
de datos entre ambos sistemas procesando varias transacciones
al mismo tiempo”.
• Con la arquitectura antigua, se generaba encolamiento de
transacciones, debido a que solamente se podía procesar una
sola transacción a la vez; actualmente, con la nueva
arquitectura, se procesan varias transacciones a la vez, hasta
ocho para ser exactos, siendo ésta una variable modificable. Hoy
se procesan más transacciones, teniendo un rango de 800
transacciones como mínimo y 1200 transacciones como máximo
por día.
Ver el siguiente cuadro:
Ilustración 12: Mínimo de transacciones por día
62
Ilustración 13: Máximo de transacciones por día
Así mismo, el encolamiento de transacciones producía malestar
y/o quejas por parte de los usuarios del almacén central y
doctores de los centros hospitalarios que lo manifestaban al área
de soporte de ayuda mediante la generación de tickets en el
sistema Vtiger.
Véase el siguiente cuadro:
Ilustración 14: Incidencias al mes por medio de tickets
30
3
0
5
10
15
20
25
30
35
Arquitectura Antigua Arquitectura Nueva
Incidencias Tickets por mes
Tickets
63
• Redujo los riesgos de desabastecimiento, actualmente se
cuenta con información exacta y oportuna entre ambos sistemas
(SALOG y SAP) para una mejor toma de decisiones en el sector
logístico de medicamentos en los centros hospitalarios de
EsSalud.
• Los usuarios se adaptaron fácilmente al sistema debido a que
en su interface de usuario no se realizó mayores cambios, las
mejoras solo fueron internas del sistema, específicamente la
arquitectura.
64
4.1.2. Presupuesto
Curva S
El presupuesto de la elaboración de un proyecto siempre va relacionado al
tiempo. En este caso, el proyecto se elaborará en tres meses.
Ilustración 15: Curva S
total S/.
Costos Quincena 1 Quincena 2 Quincena 3 Quincena 4 Quincena 5 Quincena 6 En soles
Personal 9,000.00 15,000.00 48,000.00 48,000.00 39,000.00 9,000.00 168,000.00
Equipos 3,333.33 3,333.33 3,333.33 3,333.33 3,333.33 16,666.67
Licencias 250 250 250 250 250 1,250.00
Suministros 100 200 300 500 800 1,900.00
Otros Gastos 100 200 300 500 500 500 2,100.00
Total 9,100.00 18,883.33 52,083.33 52,383.33 43,583.33 13,883.33 189,916.67
Acumulado 9,100.00 27,983.33 80,066.67 132,450.00 176,033.33 189,916.67
Mes 1 Mes 2 Mes 3
-
20,000.00
40,000.00
60,000.00
80,000.00
100,000.00
120,000.00
140,000.00
160,000.00
180,000.00
200,000.00
1 2 3 4 5 6
Co
sto
acu
mu
lad
o e
n s
ole
s
Curva "S" Series2
65
VAR y Rentabilidad del proyecto
Rentabilidad del proyecto para el cliente EsSalud:
Rentabilidad del proyecto para la empresa SALOG:
El Proyecto es técnicamente y económicamente rentable, representa
beneficios para la empresa SALOG en 18.16% y un VAN de S/. 41561.59.
Tasa de Dcto anual 12%
Tasa de Dcto mensual 0.949%
Proyecto Terceros 231,605.69
Gastos de Planilla 85,125.00
Otros gastos del
Proyecto 15,000.00
Total Proyecto 331,730.69
VANI S/. 395,203.06
VAN Neto S/. 37,501.88
Rentabilkidad del proyecto 9.49%
Periodo de Recupero 11 meses
Tasa de Dcto anual 12%
Tasa Mensual = (Tasa anual+1)^1/12 -1
Tasa de Dcto mensual 0.949%
Tasa quincenal 0.473%
VANI S/. 228,890.32
VAN NETO S/. 41,561.59
Rentabilidad VAN NETO / VANI 18.16%
66
FUENTES DE INFORMACIÓN
▪ Boletín de la Organización Mundial de la Salud - Escasez de
medicamentos a nivel mundial
http://www.who.int/bulletin/volumes/90/3/11-101303/es/
▪ Publicación de la Academia Europea de Pacientes –
Debastecimiento de medicamentos
https://www.eupati.eu/es/seguridad-de-los-
farmacos/desabastecimiento-de-medicamentos/
▪ Periódico “La Gestión”
http://gestion.pe/empresas/compania-salog-se-unio-essalud-
mejorar-servicio-entrega-medicamentos-2130691
▪ Información EsSalud
http://www.essalud.gob.pe/essalud-ya-cuenta-con-almacen-
automatizado-de-medicamentos/
▪ Tesis: Integrador de Sistemas Heredados, una Solución para la
Integración de Información
Autor: David Mauricio Sánchez
Año: 2010
▪ Tesis: “Controlador: un Framework de desarrollo para la
integración de sistema de software y cumplimiento de servicio”.
Autor:Marcelo Alejandro Collao Huper
Año: 2009
▪ Artículos sobre la comunicación entre sistemas distribuidos
mediante el modelo middleware MOM
http://www.developer.com/java/data/getting-started-with-mom-in-
jms.html
http://www.iuma.ulpgc.es/users/lhdez/inves/tesis/memoria-
tesis/node2.html
67
▪ Documentación Java - propuesta de solución
https://www.manualslib.com/manual/166161/Sun-Microsystems-
Eway-Sap-Bapi.html?page=40
68
CONCLUSIONES
• Se implementó una nueva arquitectura, mediante la metodología
SCRUM, llegando a la conclusión después de ser puesto en marcha
que se mejoró la comunicación del equipo SALOG con el cliente
EsSalud.
• Un punto principal en el éxito de la optimización sistema, fue
modificar la arquitectura, minimizando los pasos de sincronización
de data entre los sistemas de SALOG y SAP, reduciéndose de seis
a tres pasos.
• Gracias a que se implementó un procesamiento versátil, pudiéndose
realizar hasta 8 transacciones al mismo tiempo; se redujeron los
reclamos y/o incidencias concernientes al encolamiento en 90%, así
mismo se aumentó la cantidad de transacciones procesadas por día,
siendo 800 como mínimo y 1200 como máximo.
• Gracias a la nueva implementación de arquitectura, se redujo el
riesgo de desabastecimiento de medicinas en los centros
hospitalarios.
• El proyecto es viable, con una inversión inicial de 40000 soles en el
proyecto y con un TIR del 18%; el financiamiento fue proporcionado
por la misma empresa SALOG.
69
ANEXOS
Anexo 1: Flujo de comunicación entre sistema de SALOG y SAP
Los sistemas de la empresa SALOG mantienen comunicación con el
sistema SAP de EsSalud con el fin de sincronizar las transacciones
realizadas en el transcurso del día.
Debido a la gran cantidad de transacciones a sincronizar, la empresa
manejaba una atención de transacción mediante el proceso de colas:
Ilustración 16: Comunicación antigua entre SALOG y SAP
Apache Tomcat: Servidor Web
Productor: Aplicación que envía transacciones al intermediario generando
una cola.
Consumidor: Aplicación que procesa las transacciones en cola y envía a
SAP mediante RFC.
Apache Active MQ: Broker de mensajería.
70
Existe un JOB (Job Control Language) configurado en la Base de
Datos ORACLE que se ejecuta cada minuto, lee información de las
transacciones en cola en la tabla ERP_CTR_QUEUE, toma el dato ID y lo
envía al PRODUCTOR mediante HTTP (Hypertext Transfer Protocol).
La aplicación denominada PRODUCTOR envía nuevos ítems al
intermediario Active MQ generándose una cola de transacciones.
La aplicación denominada CONSUMIDOR lee los ítems que se
encuentran en la cola y los procesa uno por uno.
En el procesamiento de cada ítem de la cola, para sincronizar la
data, el CONSUMIDOR se conecta al SAP mediante el RFC.
SAP envía una respuesta al CONSUMIDOR
Si la respuesta de SAP es correcta, la transacción se almacena en
la tabla ERP_CTR_HIST, caso contrario se guarda en la tabla
ERP_CTR_ERROR.
2
4
3
5
6
1
1