ARQUITECTURA DE SOFTWARE

HERRAMIENTA DE AUTO
DIAGNOSTICO DE SALUD

Trabajo presentado por grupo 1: Nelson Alfredo Casas Sanabria

Cesar Augusto Tamayo Hernández
Manuel Octavio Rodríguez Diaz
Alejandro Rodríguez Gómez
Luis Henry Reyes Polo
Lenny Alexander Aponte Banguera
Raúl Eduardo Olier Pimienta
Omar Andrés Barreto Silva
Víctor Alfonso Dávila Martínez
Cristian Camilo Duran Mahecha

Tutora: Silva Monsalve Alexandra María

Ciudad: Bogotá (Colombia)

Fecha: 04 de octubre 2021
 1

Tabla de contenido

1. Introducción ................................................................................................................................. 3

1.1. Propósito del proyecto ......................................................................................................... 3

1.1.1. Objetivo General .......................................................................................................... 3

1.1.2. Objetivo Específicos ..................................................................................................... 3

2. Descripción de la situación de partida y planteamiento.............................................................. 4

2.1. Descripción de la entidad ..................................................................................................... 6

2.2. Identificación del problema ................................................................................................. 6

3. Metodología ................................................................................................................................. 7

3.1. Cronograma.......................................................................................................................... 8

3.2. Diseño................................................................................................................................. 10

4. Impacto en las áreas funcionales de la empresa ....................................................................... 12

4.1 Catalogo de elementos ............................................................................................................ 13

5. Planeación actividades ............................................................................................................... 13

6. Alcance ....................................................................................................................................... 14

7. Aplicación ................................................................................................................................... 15

8. Recomendaciones ...................................................................................................................... 19

9. Conclusiones .............................................................................................................................. 20

10. Referencias ............................................................................................................................. 21

11. Anexos .................................................................................................................................... 22

11.1. Glosario .......................................................................................................................... 22

 2

Tabla de Ilustraciones

Figura 1 ANTES Y DESPUÉS DE SOA ...................................................................................................... 4

Figura 2 – Porque usar Procesos Con SOA ........................................................................................... 5
Figura 3 - Integración de la aplicación propuesta ................................................................................ 6
Figura 4 Sprint Burn-Down Chart ......................................................................................................... 9
Figura 5 Finalización de Sprint Burndown Chart .................................................................................. 9
Figura 6 Ejemplo Asignación de actividades para grupo.................................................................... 10
Figura 7 Estructura Singlenton ........................................................................................................... 10
Figura 8 patrón de interacción SOA ................................................................................................... 11
Figura 9 Esquema del servicio web REST ........................................................................................... 12
Figura 10-Presentación desde el celular ............................................................................................ 16
Figura 11 Método GET Consulta de Datos ......................................................................................... 17
Figura 12- Método POST envió de Datos ........................................................................................... 17
Figura 13 Mensaje de Error Método Post .......................................................................................... 18
Figura 14 Ejemplo estructura JSON ( JavaScript Object Notation ).................................................... 18
 3

1. Introducción

Orientar las medidas generales de bioseguridad en el marco de la pandemia por el nuevo

coronavirus COVID-19, con el fin de disminuir la probabilidad de riesgo de transmisión, entre los
empleados de la empresa, nuestra necesidad ha cambiado, con la llegada del covid-19 debemos
tener cuéntala la situación diaria de nuestros empleados y el seguimiento estadístico a estado de
salud de los colaboradores de la compañía.

1.1. PROPÓSITO DEL PROYECTO

1.1.1. OBJETIVO GENERAL

Diseñar una propuesta de arquitectura de software para crear una herramienta tecnológica que le
permita a la compañía realizar seguimiento al estado de salud de sus colaboradores, con el objetivo
de que se integre en un ambiente SOA. La aplicación estará dirigida a los empleados de la compañía.

1.1.2. OBJETIVO ESPECÍFICOS

Realizar acompañamiento y orientación en tiempo real a los posibles contagios.

Realizar seguimiento al trámite de incapacidades sobre el COVID 19.
Implementar las acciones que permitan garantizar la continuidad de las actividades y la seguridad
del personal a su cargo, mediante los reportes estadísticos.
 4

2. Descripción de la situación de partida y planteamiento

A raíz de la modalidad del teletrabajo consecuencia de la emergencia sanitaria del covid-19 la

mayoría de los colaboradores laboran desde casa.
Los empleados deben informar a su jefe inmediato o supervisor, bajo la gravedad de juramento, su
sintomatología y reportará a la dependencia de recursos humanos mediante correo electrónico
reportesCovid19@miempresa.co y no debe acudir a su puesto de trabajo hasta que le descarten
que no ha sido contagiado por Covid-19.

FIGURA 1 ANTES Y DESPUÉS DE SOA

Fuente: Documento Selim, Mohamed. (2016). An Empirical Analysis on the Microservices
Architecture Pattern and Service-Oriented Architecture.
 5

Ya que la empresa cuenta con arquitectura SOA, podemos solucionar el envío de correos repetitivos
lo cual presenta mayor carga de trabajo y desinformación por parte de los jefes, conectándonos a
un servicio que será creado y publicado para el consumo de los empleados vía web.

Porque utilizar SOA, las arquitecturas SOA resuelven la necesidad de las empresas por obtener los
datos de objetos de negocio, bajo una presentación consolidada con un enfoque también de
negocio; independiente del modelo de datos donde se encuentre la información.

Evitamos que la información de objetos de negocio se encuentra dispersa en varios sistemas, por
ejemplo, los datos de un cliente pueden estar dispersos en varios sistemas, con puntos de vista
diferentes, y diferentes tipos de datos; sin embargo, sus consumidores la requieren unificada,
mediante una sola vista

FIGURA 2 – PORQUE USAR PROCESOS CON SOA

Fuente: https://sg.com.mx/content/view/329
 6

FIGURA 3 - INTEGRACIÓN DE LA APLICACIÓN PROPUESTA

Fuente: https://magmdf2014.files.wordpress.com/2014/12/soablog5.png?w=550&h=326

2.1. DESCRIPCIÓN DE LA ENTIDAD

Somos una empresa tecnológica, la cual brinda conectividad para las alcaldía y centros educativos,
cada uno con una zona wifi-implementada, donde el compromiso es brindar nuevas herramientas
tecnológicas para la educación.

2.2. IDENTIFICACIÓN DEL PROBLEMA

La empresa cuenta con más de dos mil (2000) empleados, donde nace la necesidad de monitorear
el estado de saludo de las personas trabajadoras y desarrollar protocolos de actuación para los casos
de sospecha de un posible contagio.

2.3 MAPA DE PROCESOS Y SERVICIOS

El análisis de procesos y servicios corresponde al eje de Arquitectura SOA (Arquitectura Orientada a
Servicios), ya que maximizan la reutilización de los servicios de esta manera prestan un mejor a sus
clientes.
 7

2.4 CATÁLOGO DE ELEMENTOS

El catálogo de elementos a la vista actual de los sistemas de información suministra los siguientes
artefactos desarrollados en base a la relación entre procesos, actores y aplicaciones de la institución.
El objetivo de la vista es conocer el cubrimiento funcional de las aplicaciones a las actividades de
cada uno de los procesos que integran la cadena de valor.

• Catálogo de aplicaciones por Área

• Diagrama de localización de las aplicaciones
• Matriz de actores contra aplicaciones
• Matriz de actividades contra aplicaciones

3. Metodología

Con los compañeros de estudio adoptamos la metodología SCRUM, dado que somos diez (10)
personas y entre todos podemos contribuir delegando tareas a los miembros de nuestro equipo,
realizando una estimación y planeación del proyecto basado en las necesidades del cliente.

Una de las tareas será designar nuestro equipo de desarrollo, el Product Owner quien nos ayudará
en la búsqueda de soluciones dentro de todo el proceso. Realizaremos Sprint, que son interacciones
de 1 a 4 semanas dependiendo la complejidad y se proponen reuniones diarias (Daily SCRUM), no
mayor a 15 minutos donde el equipo expone lo que hizo, lo que va a realizar y cuales impedimentos
ha tenido.
 8

3.1. CRONOGRAMA

Con el fin de realizar una estimación en el cronograma crearemos unas historias de usuario con el
fin de generar nuestro Sprint Burn-Down Chart.
Las creamos basados en como <Usuario> Quiero <algún objetivo> para qué <motivo>

• Como empleado quiero un botón que me traiga los datos de empleado para no diligenciar
más información.
• Como jefe quiero un reporte de los empleados para conocer quien este sospechoso de
contagio.
• Como usuario deseo una interfaz para gestionar el ingreso y registro de información.
• Como administrador deseo exportar la información en un archivo plano
• Como usuario deseo que me diga cuales campos son obligatorios para que no se envié sin
diligenciar.

El cronograma lo definimos lo definimos con 5 cinco números de historias en el sprint, un equipo de

10 personas en el equipo, con una jornada laboral de 1.5 horas y comenzamos el día 11/09/2021

INFORMACIÓN SOBRE EL SPRINT INFORMACIÓN DE SPRINT ACTUAL

Campo Valor
Fecha de comienzo 11/09/21 Fecha de fin de sprint 21/09/21
Longitud de sprint (bruto) 10 Longitud de sprint (neta) 10
Días de vacaciones 0 Horas disponibles totales 120
Tamaño del equipo 10 Suma de puntos de historia 69
Ocupación máxima del equipo 80% Puntos historias abiertos 69
Jornada de trabajo diaria en horas 1,5 Número de historias en el sprint 4
Número de sprints actuales 2 Historias completadas 2

La grafica Figura 4 nos presenta de color naranja la línea ideal los datos fueron tomados el día 5 es
decir que el desarrollo real con respecto a lo esperado va por buen camino, reflejando que nuestro
grupo de trabajo está comprometido con la realización de las actividades propuestas. Introduce aquí
los datos de referencia de tu proyecto. Es importante mantener la información actualizada, como
los campos de fecha de comienzo, la longitud de sprint (introduce el número bruto de días), días de
vacaciones del período de sprint, el tamaño de tu equipo, ocupación máxima deseada de tu equipo
y la jornada de trabajo diaria. Es importante conocer que cuando estamos por debajo de la línea
ideal nuestra meta va por mejor camino.
 9

FIGURA 4 SPRINT BURN-DOWN CHART

Seguimiento del cronograma

FIGURA 5 FINALIZACIÓN DE SPRINT BURNDOWN CHART

 10

ID de tarea del backlog Puntos historia Historia Asignado a Estado Completado en

1 4 a Cesar Augusto Terminado 11/09/2021
2 8 b Omar Andrés Terminado 12/09/2021
3 3 c Alejandro En curso 13/09/2021
4 8 d Lenny Alexander En curso 14/09/2021
5 13 e Omar Andrés En curso 15/09/2021
6 5 f Raul Eduardo Terminado 16/09/2021
7 8 g Cristian Camilo Sin terminar 17/09/2021
8 13 h Lenny Alexander Terminado 18/09/2021
9 4 a Victor Alfonso En curso 19/09/2021
10 3 c Nelson Alfredo Terminado 20/09/2021

FIGURA 6 EJEMPLO ASIGNACIÓN DE ACTIVIDADES PARA GRUPO

3.2. DISEÑO

Para el diseño de la aplicación utilizaremos patrones de diseño, como nuestra idea es tener un
formulario, es conveniente utilizar el patrón Singleton es creacional y nos permite asegurarnos de
que una clase tenga una única instancia, es decir tener un punto de acceso global a dicha instancia.
(Refactoring.Guru, 2021)

FIGURA 7 ESTRUCTURA SINGLENTON

La Figura 7, muestra como tenemos un punto de acceso global a dicha instancia. La clase Singleton
la podemos declarar de manera privada con el fin de declarar de manera privada sin ser accesible
de ganando el control de la clase el método estático obtener Instancia que devuelve la misma
instancia de su propia clase. El constructor del Singleton debe ocultarse del código cliente.
(Refactoring.Guru, 2021)
 11

Nos proponen utilizar la Arquitectura orientada a objetos (SOA), para nuestra herramienta nos será
muy útil ya que debemos interactuar con una aplicación de terceros es la base de y SOA es un
concepto de arquitectura software que permite construir sistemas altamente escalables, basado en
la invocación de funciones sin estado llamadas servicios. La forma más habitual de conseguir esto es
mediante el uso de Web Services. Debido a este reducido nivel de acoplamiento es más plausible
añadir nuevos servicios al sistema. (Fontenla, 2009)

Dentro de nuestra aplicación brindaremos un servicio, que se pueden llamar utilizando protocolos
de red estándar, como SOAP (protocolo simple de acceso a objetos) /HTTP o JSON/HTTP, para enviar
solicitudes para leer o cambiar datos. Los servicios se publican de tal forma que permite a los
desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas aplicaciones.
La exposición de estas funciones a través de la SOA elimina la necesidad de recrear la integración
profunda cada vez. (IBM, 2021)

FIGURA 8 PATRÓN DE INTERACCIÓN SOA

Las conexiones se realizan mediante petición - respuesta, igual que el modelo cliente-servidor,
siendo este la base de un SOA. Ahora bien, definimos el servicio a utilizar en nuestro caso escogimos
el servicio web REST, ya que incluyen la asignación que ejecutará el servicio web REST y la definición
del mensaje de respuesta que devolverá el servicio web. Los recursos también incluyen un ID de
recurso, que es un campo de clave en los datos de salida. Puede crear un recurso a partir de un
objeto de datos o bien definir manualmente un recurso.
Mensaje de solicitud
 12

Los servicios web pueden ejecutar el método HTTP GET. El mensaje de solicitud consiste en una
cadena con el nombre del servicio web, el nombre y la ubicación de red del recurso que deberá
ejecutar la tarea y los parámetros de filtrado de la salida.
Asignación de recursos
Una asignación de recursos predeterminada contiene una transformación de lectura y otra de salida
con los mismos puertos.
Mensaje de respuesta
Archivo JSON o XML que contiene los datos que se devolverán al cliente de servicio web. El mensaje
de respuesta puede contener una jerarquía de elementos y datos de ocurrencia múltiple.
(informatica, 2018)

FIGURA 9 ESQUEMA DEL SERVICIO WEB REST

Fuente: https://developrogramming.com/rest-vs-soap/

4. Impacto en las áreas funcionales de la empresa

Mejoramiento en el monitoreo de los empleados de la empresa, ya que el reporte de

Autoevaluación exitosa de la plataforma anteriormente mencionada será requisito fundamental
para el ingreso a las instalaciones de la empresa facilitando el registro del personal que labora en la
entidad y el personal que esta de manera virtual.
 13

4.1 CATALOGO DE ELEMENTOS

La vista actual de la arquitectura de datos de la institución suministra los siguientes artefactos

desarrollados en base al análisis de la recolección de muestras de información no estructurada y la
caracterización de procesos y procedimientos institucionales.
• Catálogo de entidades de negocio
• Diagrama conceptual de información

5. Planeación actividades

Para el planteamiento de las actividades con nuestro grupo se realizó consulta sobre los campos y
el diseño el formulario para captar la información del autodiagnóstico por parte de los
colaboradores en la Compañía:
REGISTRAR CUESTIONARIO y CENSO COVID-19
• No documento:
• Apellidos y nombres:
• Departamento:
• Área:
• Email:
• Celular:

DECLARACIÓN DE SALUD
CENSO
• ¿Vive con personas que presten servicios de salud?:
• Profesión:
• Contacto con:
• ¿Vive con adultos mayores de 65 años, o personas con enfermedades preexistentes?:
• Observación:

SINTOMAS ACTUALES
• Fiebre: SI/NO Observación:
• Dificulta respiratoria: SI/NO Observación:
• Vomito: SI/NO Observación:
• Congestión nasal: SI/NO Observación:
• Malestar general: SI/NO Observación:
• Tos: SI/NO Observación:
• Dolor de garganta: SI/NO Observación:
 14

• Escalofríos: SI/NO Observación:

Otros síntomas:
Fecha de inicio de los síntomas:

CONTACTO ESTRECHO
En los últimos 14 días ha tenido contacto con alguna persona con síntomas o que haya sido declarada
enferma o sospechosa para COVID-19, en las siguientes condiciones: SI/NO

Si la respuesta es sí, responda las siguientes:

• Alguno de los dos estaba sin protección respiratoria (tapabocas): SI/NO
• Estaban a una distancia menor de 2 metros: SI/NO
• Por más de 15 minutos: SI/NO
• Sin haberse lavado las manos minuciosamente después: SI/NO

PREGUNTAS SOLO PARA CASOS CON RESPUESTA POSITIVAS

• Ha consultado a su EPS por los síntomas o por los contactos positivos: SI/NO
• Ha cumplido el tiempo de aislamiento requerido para contactos o síntomas: SI/NO

AUTORIZACIÓN DE INGRESO A LA EMPRESA

• Se autoriza el ingreso al turno: APTO/ NO APTO
• Se ordena iniciar aislamiento y consultar a la EPS: SI/NO
• Vacunado: SI/NO
• Laboratorio:
• Dosis: 1 o 2
• Fecha 1era dosis: Mes/Dia/ Año
• Fecha 2da dosis: Mes/Dia/Año

6. Alcance

El proyecto culmina con el diseño e implementación bajo los lineamientos de una Arquitectura
Orientada a Servicios (SOA), facilitando la información en tiempo real, del personal que está
ejecutando sus actividades de manera presencial o virtual y manifieste síntomas como fiebre de 38°
o más o malestar general o tos persistente en su puesto de trabajo; podamos identificarlo para
protegerlo y proteger al resto de empleados, informando a su jefe inmediato o responsable del área
que se deberá ejecutar el protocolo establecido para la atención del empleado.
 15

7. Aplicación

Nuestra aplicación es una API REST ya que nos permite escalar mejor sin tener que preocuparnos de
temas como el almacenamiento de variables de sesión e incluso, podemos utilizar distintas
tecnologías para servir determinadas partes o recursos de una misma API.

Métodos en una API REST

Las operaciones más importantes que nos permitirán manipular los recursos son:
• GET es usado para recuperar un recurso.
• POST se usa la mayoría de las veces para crear un nuevo recurso. También puede usarse
para enviar datos a un recurso que ya existe para su procesamiento. En este segundo caso,
no se crearía ningún recurso nuevo.
• PUT es útil para crear o editar un recurso. En el cuerpo de la petición irá la representación
completa del recurso. En caso de existir, se reemplaza, de lo contrario se crea el nuevo
recurso.
• PATCH realiza actualizaciones parciales. En el cuerpo de la petición se incluirán los cambios
a realizar en el recurso. Puede ser más eficiente en el uso de la red que PUT ya que no envía
el recurso completo.
• DELETE se usa para eliminar un recurso.

La Figura 10-Presentación desde el celular, representamos la manera de visualizarlo desde un

dispositivo electrónico con este fin damos acceso a la aplicación a más usuarios de la empresa.
 16

FIGURA 10-PRESENTACIÓN DESDE EL CELULAR

Mensajes de Error método POST

 17

FIGURA 11 MÉTODO GET CONSULTA DE DATOS

FIGURA 12- MÉTODO POST ENVIÓ DE DATOS

 18

FIGURA 13 MENSAJE DE ERROR MÉTODO POST

FIGURA 14 EJEMPLO ESTRUCTURA JSON ( JAVASCRIPT OBJECT NOTATION )

 19

8. Recomendaciones

Nuestro grupo recomienda el uso de un cifrado SSL (Secure Sockets Layer), para nuestra API RESTful,
dado que se puede acceder a la web de su API desde cualquier lugar con acceso a Internet.
Asimismo, el uso de métodos de autentificación API REST como los son, Autentificación básica
Autentificación basada en token, Autentificación basada en clave API, OAuth 2.0 (Autorización
abierta)
Utilizaremos en este caso un sistema API debe generar una clave (key) y un secret key para cada
cliente que requiera acceso a tus servicios. Cada vez que una aplicación necesite consumir los datos
de tu API, deberás enviar tanto la key como la secret key. (Itdo, 2021)
 20

9. Conclusiones

El documento nos refleja que nuestros usuarios finales no podrán ver el tipo de arquitectura
utilizado, es importante comprender cómo actúa SOA a través de componentes débilmente
acoplados y cómo estas son las bases de toda la arquitectura, intercambiando datos en el proceso
para entrega de un servicio.
La arquitectura de software propuesto facilita a los usuarios realizar el debido reporte de
autodiagnóstico durante la emergencia sanitaria actual.
 21

10. Referencias

contributors, M. a. (21 de jun. de 2019). Obtenido de MDN web docs :

https://developer.mozilla.org/es/docs/Web/API/WebSockets_API/Escribiendo_servidores
_con_WebSocket
Fontenla, J. &. (2009). Una Arquitectura SOA para sistemas de e-Learning a través de la integración
de Web Services. Universidad de Vigo: Congreso Iberoamericano de Telemática.
IBM. (14 de 09 de 2021). IBM. Obtenido de
https://www.ibm.com/docs/es/rsas/7.5.0?topic=overview-web-services-standards
informatica. (18 de 07 de 2018). Informatica. Obtenido de
https://docs.informatica.com/es_es/data-integration/data-services/10-1-1-hotfix-1/web-
services-guide/servicios-web-rest/resumen-de-servicios-web-rest.html
Itdo. (2 de 10 de 2021). Obtenido de https://www.itdo.com/blog/cual-es-el-mejor-metodo-de-
autentificacion-en-un-api-rest/
mintic. (15 de 09 de 2021). mintic. Obtenido de https://mintic.gov.co/arquitecturati/630/w3-
propertyvalue-8161.html
Platzi. (14 de 09 de 2021). platzi. Obtenido de https://platzi.com/glosario/
Refactoring.Guru. (15 de 09 de 2021). Obtenido de https://refactoring.guru/es/design-
patterns/singleton
 22

11. Anexos

11.1. GLOSARIO

Automatización: Procesos automatizados para procesamiento de información.

Ambiente (de desarrollo, pruebas o producción): Es la infraestructura tecnológica (hardware y

software) que permite desarrollar, probar o ejecutar todos los elementos o componentes para
ofrecer un servicio de Tecnologías de la Información.

Arquitectura de software: Describe el conjunto de componentes de software que hacen parte de

un sistema de información y las relaciones que existen entre ellos. Cada componente de software
está descrito en términos de sus características funcionales y no funcionales. Las relaciones se
expresan a través de conectores que reflejan el flujo de datos, de control y de sincronización. La
arquitectura de software debe describir la manera en que el sistema de información maneja
aspectos como seguridad, comunicación entre componentes, formato de los datos, acceso a
fuentes de datos, entre otros. (mintic, 2021)

Caso de negocio: Es una argumentación estructurada y fundamentada (usando distintos tipos de

análisis) que permite mostrar la conveniencia de desarrollar alguna acción, proyecto, adquisición o
contratación. En el caso particular de TI corresponde a la justificación, guiada por la estrategia global
de la institución, de las acciones que se desarrollan.

Criterios de aceptación: Son un conjunto preciso y bien definido de condiciones que un producto
que se va a adquirir o construir debe satisfacer en el momento de su entrega, para que sea aceptado
por una entidad.

Dominio: Los dominios son las dimensiones desde las cuales se debe abordar la gestión estratégica.
Agrupan y organizan los objetivos, áreas y temáticas relativas.

Estándares: Es un documento que contiene un conjunto de especificaciones técnicas de aplicación

voluntaria, que ha sido construido a través de consenso y que refleja la experiencia y las mejores
prácticas en un área en particular.

Flujo de información: Corresponde a la descripción explicita de la interacción entre proveedores y

consumidores de información, con un patrón repetible de invocación definido por parte de la
entidad. Puede incorporar servicios de información, datos e información.

Formularios: Conjunto de campos, generalmente acompañados de información que permite al

usuario interaccionan con la aplicación.

Publicar: Un proveedor comunica a los clientes cómo invocar el servicio web.

 23

Punto de vista arquitectural: Una arquitectura, en general, es el conjunto de estructuras que

constituyen un sistema. Cada una tiene, entre otras cosas, un grupo de componentes y sus
relaciones. Un punto de vista de una arquitectura es un subconjunto de componentes y relaciones,
provenientes de una o varias estructuras, con un significado o interés particular dentro del sistema.
Una vista es el cálculo de un punto de vista sobre una arquitectura específica.

Roles: Conjunto de responsabilidades y actividades asignadas a una persona o grupo de personas

para apoyar la adopción y aplicación del Marco de Referencia de Arquitectura Empresarial

Servidor: Cuando una página web es visitada, los datos se envían desde alguna computadora a
algún lugar a tu computadora a través del internet. Esa otra computadora es un servidor,
configurada especialmente para entregar información a otras computadoras que la soliciten.
(Platzi, 2021)

Scrum: Es un marco de trabajo ligero que ayuda a las personas, equipos y organizaciones a generar
valor mediante soluciones adaptativas a problemas complejos.

Sprint (Evento): Es un período de tiempo fijo en el cual se realiza el trabajo y que contiene los
otros eventos de Scrum

SOAP (Simple Object Access Protocol): este protocolo complejo define una gramática XML con
el formato de los documentos que se deben intercambiar entre quien realiza la solicitud (cliente) y
quien la responde (servicio) por lo general se utiliza en los servicios web.