2020

FUNDACIÓN CENTRO COLOMBIANO DE ESTUDIOS PROFESIONALES

Jenniffer Paola Orjuela Lozano

Oscar Alexander Castillo

SGOC – SISTEMA DE GESTION DE ORDENES DE COMPRA

[Análisis del desarrollo de una arquitectura de software para la implementación de
una aplicación “SGOC” (Sistema de Gestión de Órdenes de Compra) que permita
a los agentes de una empresa ingresar las órdenes de compra de sus clientes,
validar, procesar las órdenes y notificar a los clientes de los estados de sus
compras.]
 CONTROL DE VERSIONES

Fecha Versión Descripción Autor Revisó Aprobó

Versión inicial Jenniffer Orjuela
16/04/2020 1.0
del documento Alexander Castillo
Cambios Jenniffer Orjuela
24/04/2020 1.1
Diagramas Alexander Castillo
 TABLA DE CONTENIDO

Pág.

1 GENERALIDADES DEL PROYECTO .............................................................. 3

1.1 PROBLEMA A RESOLVER ....................................................................... 3

1.2 DESCRIPCIÓN GENERAL DEL SISTEMA A DESARROLLAR ................. 4

1.3 OBJETIVOS ............................................................................................... 5

1.4 STAKEHOLDERS ...................................................................................... 5

2 REQUERIMIENTOS ......................................................................................... 6

2.1 REQUERIMIENTOS FUNCIONALES ........................................................ 6

2.2 REQUERIMIENTOS DE ATRIBUTOS DE CALIDAD ................................. 8

2.3 MODELO DE CASOS DE USO ................................................................. 9

3 ÁRBOL DE UTILIDAD .................................................................................... 10

3.1.1 DIAGRAMA DE UT ............................................................................ 10

3.1.2 TABLA DE ESPECIFICACIÓN DE ÁRBOL DE UTILIDAD (OPCIONAL
SI SU DIAGRAMA DE UT NO ES CLARO) .......Error! Bookmark not defined.
4 ESCENARIOS DE CALIDAD PRIORIZADOS ................................................ 11

5 DEFINICIÓN DE TÁCTICAS , ESTRATEGIAS Y/O PATRONES DE

ARQUITECTURA .................................................................................................. 11

6 DEFINICIÓN DE PATRONES DE DISEÑO DE SOFTWARE......................... 15

7 DIAGRAMA DE CLASES CON PATRONES DE DISEÑO IMPLEMENTADOS

16

8 DIAGRAMA DE PAQUETES ABSTRACTOS ................................................. 17

9 DIAGRAMA DE COMPONENTES .................................................................. 17

10 LISTA DE INTEGRACIONES ...................................................................... 18

 1 GENERALIDADES DEL PROYECTO

1.1 PROBLEMA A RESOLVER

Se requiere realizar el análisis y plantear una arquitectura de software para el caso

de estudio planteado en la materia “Electiva II” por la profesora Olga:

Consideremos una compañía que desea implementar una aplicación por medio de
la cual les permita a sus agentes de ventas (vendedores) ingresar las órdenes de
compra de sus clientes al sistema de órdenes de compra, validar y procesar dichas
órdenes y notificar del hecho cuando cada pedido está ya en proceso para ser
enviado. Los agentes de venta se mueven por todo el país, algunos tienen la
posibilidad de usar computadores de escritorio o portátiles para enviar las ordenes
nuevas, otros disponen de teléfonos inteligentes desde donde pueden cargar dichas
ordenes al sistema. Al enviar una orden nueva esta debe ser validada antes de ser
enviada al sistema de órdenes. La validación consiste en chequear contra el sistema
de clientes si los datos del cliente ingresados en la orden nueva son válidos y si este
tiene una forma válida de pago. Una vez validada, los datos de la orden son
almacenados en el sistema de procesamiento de órdenes y un correo electrónico
debe ser generado para informar al cliente que su orden está siendo procesada. El
sistema debe evitar que una orden enviada por un agente no sea procesada o sea
desestimada antes de ser ingresada al sistema de órdenes de compra. En
momentos de uso intensivo se estiman hasta 200 usuarios concurrentes. Los
viernes en la tarde se cierra el ingreso de nuevas órdenes para poder asegurar la
entrega de los artículos por el lunes siguiente por lo que normalmente alrededor de
5.000 órdenes llegan a través de los diferentes medios cinco minutos antes del
cierre de la semana. Se desea que el sistema implementado garantice que no se
perderán ordenes que por motivos de congestión no alcancen a ser procesadas por
el sistema.

El sistema de órdenes de compra se ejecuta sobre un servidor en plataforma .Net

mientras que el sistema de clientes es una aplicación escrita en lenguaje java, J2EE
que usa una base de datos MySQL, aunque se está considerando migrar a Oracle
10g. El servidor de correo electrónico usado por la compañía es el provisto por
Google App.”
1.2 DESCRIPCIÓN GENERAL DEL SISTEMA A DESARROLLAR
1.3 OBJETIVOS ESTRATEGICO

No Descripción
OE1 Brindar diferentes medios digitales para el ingreso de ordenes de compra
OE2 Permitir el acceso simultaneo de máximo 5000 usuarios.
OE3 Mantener la persistencia de los datos en la interacción entre servicios.
OE4 Certificar la seguridad de la información al 98%.
OE5 Aumentar las ventas en un 20% atreves de la aplicación.

1.4 STAKEHOLDERS

Stakeholder Descripción
Agentes de ventas Es el usuario vendedor que ingresa los datos de las
órdenes de compra y podrá crear clientes en la aplicación.
Clientes Es el insumo principal para generar las órdenes de
compra.
 2 REQUERIMIENTOS

2.1 REQUERIMIENTOS FUNCIONALES

No. Objetivo
RQF No. Especificación de Requisito
Estratégico
Se requiere una pantalla en la app SGOC para visualizar el
1 OE5
formulario de inicio de sesión
Se requiere una funcionalidad en la app SGOC que permita
2 validar en el sistema de nómina el usuario y contraseña OE3
ingresados por el asesor de ventas
Se requiere una pantalla en la app SGOC para crear las
3 OE3
órdenes de compra
Se requiere una funcionalidad en la app SGOC que permita
4 OE3
validar la existencia del cliente en el sistema de Clientes
Se requiere una funcionalidad en el sistema SGOC que
5 permita crear los clientes si no existen en el sistema de OE3
Clientes
Se requiere una funcionalidad en la app SGOC que permita
6 validar el medio de pago del cliente en el sistema de OE3
clientes
Se requiere una funcionalidad en la app SGOC que permita
7 validar la existencia del producto en el sistema de OE3
inventarios
Se requiere una funcionalidad en la app SGOC que permita
8 almacenar la orden de compra cuando la app está en OE3
estado offline
Se requiere una funcionalidad en la app SGOC que permita
9 almacenar la orden de compra con la posibilidad de asignar OE5
productos sin stock
Se requiere una funcionalidad en la app SGOC que permita
10 OE5
clasificar el tipo de la orden de compra (con stock/sin stock)
Se requiere una funcionalidad en la app SGOC que permita
enviar un correo electrónico de notificación al cliente sobre
11 OE5
el estado de la orden de compra a través del sistema de
correos
Se requiere una pantalla en la app SGOC para visualizar el
12 formulario de configuración de cierre de sistema con una OE5
hora, día de cierre y hora, día de apertura
Se requiere una funcionalidad en el sistema SGOC que
13 permita cerrar el sistema de orden de compra según fecha OE5
configurada
Se requiere una funcionalidad en el sistema SGOC que
14 permita abrir el sistema de orden de compra según fecha OE5
configurada
 Se requiere una funcionalidad en la app SGOC que permita
15 el ingreso masivo de más de 5000 órdenes de compra en OE2
un mismo lapso de tiempo
Se requiere una funcionalidad en la app SGOC que permita
almacenar en cola las órdenes de compra ingresadas
16 OE5
después del cierre del sistema hasta la nueva apertura del
mismo
Se requiere una funcionalidad en la app SGOC que permita
17 sincronizar las ordenes de compra almacenadas en cola OE3
durante el cierre del sistema.
Se requiere una funcionalidad en la app SGOC que permita
sincronizar las órdenes de compra en el sistema de órdenes
18 OE3
de compra y los clientes en el sistema de clientes, creados
cuando la app está en estado offline
Se requiere una funcionalidad en la app SGOC que permita
19 el registro de cada movimiento que realice el usuario en el OE4
aplicativo
Se requiere una funcionalidad en la app SGOC que permite
20 cifrar la conexión de la app por un protocolo de cifrado de OE4
SSL
Se requiere que el sistema SGOC tarde menos de 5
21 segundos en realizar la validación de usuario y contraseña OE3
en el sistema de nómina
Se requiere que el sistema SGOC tarde menos de 10
22 segundos validando la existencia de clientes en el sistema OE3
de clientes
Se requiere que el sistema SGOC tarde menos de 10
23 segundos validando la existencia de métodos de pago en el OE3
sistema de cliente
Se requiere que el sistema SGOC tarde menos de 10
24 segundos validando la existencia de los productos en el OE3
sistema de inventarios
Se requiere que el sistema SGOC se conecte de manera
25 OE4
segura al sistema de nómina
Se requiere que el sistema SGOC bloquee la IP del usuario
26 si éste ingresa de manera incorrecta más de 3 veces su OE4
contraseña
Se requiere que el sistema SGOC se conecte de manera
27 OE4
segura al sistema de clientes
Se requiere que el sistema SGOC se conecte de manera
28 OE4
segura al sistema de inventarios
Se requiere que el sistema SGOC se conecte de manera
29 OE4
segura al sistema de mensajería
Se requiere que el sistema SGOC permita la conexión
30 OE2
simultánea de 5000 usuarios
 Se requiere que el sistema SGOC tenga una interfaz de
31 OE5
usuario fácil de usar
Se requiere que el sistema SGOC cuente con ayudas
32 OE5
visuales en sus formularios para prevenir errores de usuario
Se requiere que el sistema SGOC cuente con mensajes de
33 excepciones claros para orientar al usuario y/o OE5
administrador del sistema
Se requiere que el sistema SGOC sea accesible desde
34 OE1
cualquier sistema operativo
Se requiere que el sistema SGOC sea accesible desde
35 OE1
cualquier tipo de dispositivo (Escritorio, Movil)

2.2 REQUERIMIENTOS FUNCIONALES ASOCIADO A ATRIBUTOS DE

CALIDAD

Atributo de Calidad RQF Asociado

Disponibilidad 8, 12, 16, 17
Escalabilidad 15, 17, 18, 33
Desempeño 13, 14, 15, 16, 19, 21, 22, 24, 30
Seguridad 2, 19, 20, 25, 26, 27, 28, 29
Portabilidad 34, 35
Integralidad 2, 4, 5, 6, 7, 11, 13, 14, 17, 18
Interoperabilidad 2, 4, 5, 6, 7, 11, 13, 14, 17, 18
2.3 MODELO DE CASOS DE USO
 3 ÁRBOL DE UTILIDAD

3.1.1 DIAGRAMA DE UT
4 ESCENARIOS DE CALIDAD PRIORIZADOS

Escenario de Calidad No. 1 Stakeholder Tester

Atributo de Calidad Interoperabilidad
Justificación La comunicación no debe presentar perdida de paquetes
Fuente Tester
Estímulo Almacenamiento de información en sistema externo
Artefacto Sistema SGOC
Ambiente Bajo validación de pruebas
El sistema SGOC envía los paquetes completos al sistema
Respuesta
destino
Taza de información intercambiada correctamente debe ser
Medida de la Respuesta
del 100%

Escenario de Calidad No. 2 Stakeholder Usuario

Atributo de Calidad Seguridad
Justificación El acceso a la aplicación debe ir cifrado por protocolo SSL
Fuente Usuario
Estímulo Acceso a la aplicación
Artefacto Sistema SGOC
Ambiente Uso cotidiano de la aplicación
Respuesta Bloquear el acceso sin protocolo seguro SSL
Cantidad de datos vulnerables ante un ataque debe ser
Medida de la Respuesta
inferior a un 20%

Escenario de Calidad No. 3 Stakeholder Desarrollador

Atributo de Calidad Seguridad
Justificación La comunicación con otras aplicaciones debe ir cifrada
Fuente Desarrollador
Estímulo Comunicación con sistemas externos
Artefacto Sistema SGOC
Ambiente Desarrollo de la aplicación
Respuesta Bloquear conexiones sin cifrado de información
Cantidad de servicios vulnerables ante un ataque debe ser
Medida de la Respuesta
inferior al 10%
Escenario de Calidad No. 4 Stakeholder Tester
Atributo de Calidad Usabilidad
Justificación Debe existir logs de información para orientar a los usuarios
Fuente Tester
Estímulo Excepciones del sistema
Artefacto Sistema SGOC
Ambiente Bajo validación de pruebas
Respuesta Generación de archivo con información del error del sistema
porcentaje de errores documentados al ejecutar las tareas
Medida de la Respuesta
deben ser del 100%

Escenario de Calidad No. 5 Stakeholder Tester

Atributo de Calidad Portabilidad
El acceso al sistema debe permitirse desde cualquier
Justificación
sistema operativo y dispositivo
Fuente Tester
Estímulo Acceso a la aplicación
Artefacto Sistema SGOC
Ambiente Bajo validación de pruebas
Permitir acceso desde cualquier dispositivo y sistema
Respuesta
operativo
Medida de la Respuesta Porcentaje de aceptabilidad del 100%

Escenario de Calidad No. 6 Stakeholder Tester

Atributo de Calidad Desempeño
El tiempo de respuesta a consultas sobre otros sistemas no
Justificación
debe superar los 10 segundos
Fuente Tester
Estímulo Conectividad a otros sistemas
Artefacto Sistema SGOC
Ambiente Bajo validación de pruebas
Respuesta Acceso a otros sistemas en tiempos aceptables
Medida de la Respuesta Latencia inferior a 10 segundos
Escenario de Calidad No. 7 Stakeholder Tester
Atributo de Calidad Desempeño
Los accesos a la aplicación deben soportar más de 5000 en
Justificación
simultanea
Fuente Tester
Estímulo Uso de la aplicación
Artefacto Sistema SGOC
Ambiente Bajo validación de pruebas
El sistema no debe bloquearse con una concurrencia de
Respuesta
5000 usuarios
Medida de la Respuesta Acceso en simultanea de 5000 usuarios

Escenario de Calidad No. 8 Stakeholder Desarrollador

Atributo de Calidad Modificabilidad
Al realizar modificaciones en los módulos de la aplicación
Justificación
dichas modificaciones no deben tardar más de un mes
Fuente Desarrollador
Estímulo Modificación de funcionalidades del sistema
Artefacto Sistema SGOC
Ambiente Entorno de desarrollo
La modificación a funcionalidades debe orientarse a periodos
Respuesta
cortos
Medida de la Respuesta Tiempo de modificación inferior a 30 días

Escenario de Calidad No. 9 Stakeholder Tester

Atributo de Calidad Testeabilidad
El tiempo de creación para la documentación de pruebas no
Justificación
debe ser superior a 8 horas por módulo
Fuente Tester
Estímulo Creación de documentos de pruebas
Artefacto Sistema SGOC
Ambiente Bajo creación de pruebas
Respuesta Documentación de pruebas en lapsos cortos de tiempo
Medida de la Respuesta Costo requerido para diseñar las pruebas inferiores a 8 horas
 Escenario de Calidad No. 9 Stakeholder Tester
Atributo de Calidad Testeabilidad
El tiempo de ejecución de pruebas no debe superar las 4
Justificación
horas por módulo
Fuente Tester
Estímulo Ejecución de pruebas
Artefacto Sistema SGOC
Ambiente Bajo ejecución de pruebas
Respuesta Ejecución de pruebas en lapsos cortos de tiempo
Esfuerzo requerido para diseñar las pruebas inferiores a 4
Medida de la Respuesta
horas por módulo

5 DEFINICIÓN DE TÁCTICAS, ESTRATEGIAS Y/O PATRONES DE

ARQUITECTURA

Atributo de
Rq. de
¿Cómo la define? Calidad Justificación
Descripción Calidad
Asociado
Táctica Estrategia Patrón
Asegurar
Se debe verificar que el
que un
usuario que intenta acceder Arquitectura
Autenticar a los usuario es
tiene permisos y está Seguridad Basada en Seguridad 25, 26
usuarios. realmente
autorizado para acceder e Capas
quien dice
ingresar datos.
ser
Los datos
El cifrado es la única
deben estar
protección para pasar los Mantener la Arquitectura
protegidos
datos a través de enlaces de Seguridad confidencialidad Basada en Seguridad 20
contra el
comunicación de acceso de los datos. Capas
acceso no
público.
autorizado
se conecte
Puede tener información
de manera
redundante codificada en
Arquitectura segura al
ella que pueden ser Mantener la 27, 28,
Seguridad Basada en Seguridad sistema de
encriptados con o integridad 29
Capas clientes,
independientemente de los
inventarios y
datos originales.
mensajería.
Debe
permita el
Se debe certificar que ingreso
cuando varias peticiones Arquitectura masivo de
Contención del
llegan al mismo tiempo se Rendimiento Basada en Desempeño 15, 30 más de 5000
recurso
mantenga los datos y se Capas órdenes de
guarden correctamente. compra en
un mismo
lapso.
Debe tardar
Debe esperar los resultados menos de 5
Arquitectura
de otro proceso para Tiempo de 21, 22, segundos en
Rendimiento Basada en Desempeño
computarlos en conjunto y Bloqueo 23, 24 realizar la
Capas
dar así una respuesta. validación de
usuario y
 contraseña
en el sistema
de nómina.
Se debe
permitir
sincronizar
las órdenes
Preparación para la Detección de Arquitectura
de compra
recuperación y reparación Disponibilidad Fallas / Basada en Disponibilidad 16, 17
almacenadas
del sistema Heartbeat Capas
en cola
durante el
cierre del
sistema.
La app debe
contar con
ayudas
visuales en
sus
Se soporta en un modelo de
Arquitectura formularios
información que puede ser System - 31, 32,
Usabilidad Basada en para prevenir
acerca de: el usuario, la Initiative 33,
Capas errores de
tarea, el sistema.
usuario y
debe tener
una interfaz
de usuario
fácil de usar.

6 DEFINICIÓN DE PATRONES DE DISEÑO DE SOFTWARE

Atributo de Calidad Requerimiento de
Patrón de Diseño Descripción ¿Por qué?
Asociado Calidad
Se encarga que la
Capa de datos;
lógica de negocio y
Arquitectura contiene la lógica de Integralidad,
2, 4, 5, 6, 7, 11, 17, 18 transacciones sean
Basada en Capas comunicación con Interoperabilidad
independientes y
otros sistemas.
mantenibles.
Presenta el sistema
Capa de al usuario, le
presentación; comunica la
Arquitectura Usabilidad, 1, 3, 12, 13, 14, 31, 32,
referente a la información y
Basada en Capas Portabilidad 33, 34, 35
interacción entre el captura la
usuario y el software. información del
usuario.
Capa de reglas de
negocio; es donde se
establecen todas las
Contiene la
reglas que deben Usabilidad,
funcionalidad que
cumplirse, los Integralidad,
Arquitectura implementa la
programas que se Interoperabilidad, 4, 6, 7, 10, 13, 14, 19, 26
Basada en Capas aplicación, involucra
ejecutan, se reciben Seguridad,
validaciones,
las peticiones del Disponibilidad
cálculos.
usuario y se envían
las respuestas tras el
proceso
7 DIAGRAMA DE CLASES CON PATRONES DE DISEÑO IMPLEMENTADOS
DIAGRAMA DE PAQUETES ABSTRACTOS

8 DIAGRAMA DE COMPONENTES
 9 LISTA DE INTEGRACIONES
Tipo Protocolo de
Id Descripción Proveedor Consumidor
Integración Integración
INT001 Login Colaborador Servicio web Backend-Nomina Front-End Rest
INT002 Validación Cliente Servicio Web Backend-Clientes Front-End Rest
INT003 Validación Método Pago Servicio Web Backend-Clientes Front-End Rest
INT004 Validación Producto Servicio Web Backend-Inventarios Front-End Rest
INT005 Almacenar Orden Compra Servicio Web Backend-OrdenesCompra Front-End Rest
INT006 Envió de Notificación Servicio Web Backend-Mensajeria Front-End Rest
Sincronización Offline Creación
INT007 Servicio Web Backend-OrdenesCompra Front-End Rest
de Ordenes de compra
Sincronización Offline Creación
INT008 Servicio Web Backend-Clientes Front-End Rest
de Clientes