Métodos de Análisis de Puntos de

Riesgo en un Arquitectura (ATAM)

El Architecture Tradeoff Analysis Method (ATAM) obtiene su nombre no solo

porque nos dice cuan bien una arquitectura particular satisface las metas de
calidad, sino que también provee ideas de cómo esas metas de calidad
interactúan entre ellas, como realizan concesiones mutuas entre ellas.

Tener un método estructurado, permite hacer el análisis repetible y ayuda a

asegurar que las preguntas acerca de una arquitectura serán contestadas en
forma temprana, cuando es relativamente económico corregir problemas.

El ATAM también puede ser utilizado para analizar sistemas legados. Esta
necesidad nace cuando el sistema legado necesita ser modificado, integrado con
otro sistema, entre otras necesidades. Aplicar el ATAM incrementa el
entendimiento de los atributos de calidad del sistema legado.

1. Resumen de los pasos del ATAM

La parte principal del ATAM consta de nueve pasos. Estos pasos se dividen
cuatro grupos:

 Presentación, donde la información es intercambiada.

 Investigación y análisis, donde se valoran los atributos claves de
calidad requeridos, uno a uno con las propuestas arquitectónicas.
 Pruebas, donde se revisan los resultados obtenidos contra las
necesidades relevantes de los stakeholders.
 Informes, donde se presentan los resultados del ATAM.

1.1 Presentación

1. Presentar el ATAM
El líder del equipo de evaluación describe el método a los participantes,
fija las expectativas y responde las preguntas que puedan surgir.

2. Presentar las pautas del negocio

Un representante del proyecto (por ejemplo, el director de proyecto o el
cliente del sistema) describe las metas del negocio que motivan el
esfuerzo de desarrollo y que se convertirán en las pautas primordiales de
la arquitectura (por ejemplo, alta disponibilidad o alta seguridad).

3. Presentar la arquitectura
El arquitecto describe la arquitectura, enfocándose en como esta sigue las
pautas del negocio.
 1.2 Investigación y análisis

4. Identificar las propuestas arquitectónicas

Las propuestas arquitectónicas son identificadas por el arquitecto, pero
no son analizadas.

5. Generar el árbol de utilidad de los atributos de calidad

Los atributos de calidad que comprometen la utilidad del sistema
(rendimiento, disponibilidad, entre otros) son obtenidos, especificados en
escenarios (con estímulos y respuestas) y priorizados.

6. Analizar las propuestas arquitectónicas

Basados en los escenarios de mayor prioridad identificados en el paso 5,
las propuestas arquitectónicas que cumplen con estos escenarios son
obtenidas y analizadas (por ejemplo, una propuesta arquitectónica que
logra una meta de performance será objeto de un análisis de
performance).
Durante este paso los riesgos arquitectónicos, los no riesgos, los
sensitivity points y tradeoff points son identificados.

1.3 Pruebas

7. Lluvia de ideas y priorización de escenarios

Un gran conjunto de escenarios es obtenido por todos los stakeholders.
Este conjunto es priorizado mediante votación.

8. Analizar las propuestas arquitectónicas

En este paso se reitera las actividades del paso 6 utilizando el ranking de
escenarios del paso 7. Estos escenarios se consideran casos de prueba
para confirmar el análisis realizado hasta ahora. Este análisis puede
descubrir nuevas propuestas arquitectónicas, riesgos, no riesgos,
sensitivity points y tradeoff points, que son documentados.

1.4 Informes

9. Presentar los resultados

Basados en la información recogida durante el ATAM (propuestas, escenarios,
árbol de utilidad, riesgos, no riesgos, sensitivity points y tradeoff points), el equipo
de ATAM presenta los resultados a los stakeholders

2. Arquitectura Sium
2.1 Introducción

El mundo de las tecnologías de la información ha cambiado

dramáticamente en la última década. El auge de la tecnología móvil y la
creciente sofisticación de las plataformas web han dado a las empresas
en el sector industrial una enorme ventaja competitiva sobre sus rivales.
Incluso el más rudimentario sistema de apoyo genera datos que
permiten al equipo gerencial mejorar fácilmente el análisis empleado –
 productividad, lo que mantiene un control respectivo más a menudo. Los
recientes estudios ven a las tecnologías de información y comunicación
como cualquier otro tipo de capital, las tic pueden ser usadas
directamente como una tecnología de producción que permite mejorar
la productividad laboral, por lo que encontramos una conexión directa
entre las inversiones en tic y el crecimiento de la productividad, tanto si
se analizaba a nivel de empresa, de industria o de la economía en su
conjunto, estos avances han creado una necesidad crítica para las
empresas a estar innovando en todas sus áreas rápidamente para
permanecer competitivo.
Curiosamente, uno de los principales impulsores del crecimiento de las
tic son los dispositivos móviles y el omnipresente acceso Wi-Fi, de
hecho, puede ser esta la llave para nivelar el campo de juego en los
diversos sectores.

Los gerentes han sido capaces de comprender el comportamiento de los

empleados a su cargo para optimizar su lealtad y compromiso, midiendo
sus comportamientos habituales, qué necesita y cuan rápido se brinda
la ayuda necesaria.
Pero ¿cómo puede un gerente obtener un control a tiempo real para
mejorar su eficiencia operacional?

2.2 Solución ofrecida

Todas las maquinarias de Soldexa, alojadas en las instalaciones, tendrán

incorporado un módulo de control y supervisión ESP-8086 , los gerentes
tendrán acceso vía web a un control en vivo de todas las maquinarias
registradas en el portal, permitiendo un mejor control de sus empleados
para poder tomar las medidas correctivas respectivas y solucionar
problemas lo más rápido posible, incluso a través de miles de lugares de
trabajo.
Los gerentes pueden optar por ver graficas de las maquinarias que
tienen a cargo y generar reportes de los indicadores de uso obtenidos
durante un rango establecido.

2.3 Algunas de las métricas disponibles en la solución son:

 Disponibilidad
  Pérdidas de Tiempo Productivo por Paradas.

 Rendimiento

 Pérdidas de velocidad por pequeñas paradas.

 Pérdidas de velocidad por reducción de velocidad.

 Calidad

 Pérdidas por Calidad.

 Pérdidas de Calidad, igual al número de unidades mal
fabricadas.
 Pérdidas de Tiempo Productivo, igual al tiempo empleado en
fabricar las unidades defectuosas.
 Tiempo de reprocesado.
 Coste de tirar, reciclar, etc. las unidades malas.

2.4 Requisitos Funcionales

 El Analista de Producción podrá visualizar las estadísticas de

maquinaria
 El Analista de Producción podrá tener acceso al reporte generado
para cada turno
 El Analista de Producción podrá tener acceso a un historial de
reportes
 El Analista de Producción podrá configurar maquinaria

2.5 Requisitos No Funcionales

 Disponibilidad: El sistema debe almacenar la información de los

clientes las 24 horas del día, los 7 días a la semana.
 Rendimiento: El sistema debe brindar información del estado de las
maquinarias en un tiempo no mayor a 5 segundos

2.6 Conclusión sobre Sium

Las empresas de todos los sectores están acelerando la implementación

de las redes Wi-Fi para mejorar las posibilidades de desarrollo e
innovacion en la planta y mejorar la productividad de los empleados.
Esta inversión representa una oportunidad de oro para llevar al negocio
a la cima con respecto a sus rivales.
Las empresas que no empleen tic en sus áreas tanto de desarrollo como
de otras áreas están destinadas a perecer frente al nuevo desarrollo
económico e innovacion. Al pasar a la toma de decisiones basada en
datos, las son capaces de mejorar el negocio de maneras que antes no
era posible.
3. Arquitectura

3.1 Restricciones técnicas

Para esta arquitectura es necesario contratar servicios de la empresa

Amazon, como son:

 Amazon EC2. Un servicio de almacenamiento en nube.

 mLab. Un hosting de base de datos online.

Otras restricciones como:

 La base de datos estará montada en MongoDB.

 La plataforma será orientada a Web.

Requerimientos de Hardware:

 ESP8288.
 DS-3231.
 Sensor de Vibracion o corriente

3.2 Sistemas con los que interactua

Interactúa con el sistema “Amazon S3” quien contiene los servicios de

la empresa Amazon.
Además, hace uso del sistema de almacenamiento en nube de
Windows “Azure” al momento de interactuar con mLab, que esta
alojado en esta.

3.3 Propuesta de arquitectónica

La información recopilada será mostrada via web con las

características principales de Dashboard, reportes, herramientas de
gestión.

Dashboard Reportes Estado

 Haciendo uso del sistema de gestión de módulos de Arduino,
implementamos un software que recopile la información del tiempo y
comportamiento de las maquinarias, conectándose via wiFi para ser
recepcionados mediante el broker Mosquitto por parte del servidor.
Siendo enviado posteriormente al repositorio en la nube.

El estilo arquitectónico cliente servidor de 3 capas, permitirá que el

acceso a la data recopilada pueda ser accedida dependiendo del
hardware utilizado. Además de permitir un acceso sencillo a los módulos
de Arduino, que dado el caso maximizara la disponibilidad, además del
rendimiento gracias a los servicios de optimización brindados por
Amazon, que raramente presentan fallas dado que sus sistemas son
muy robustos.

El estilo arquitectónico centrado en datos permitirá que el módulo de

presentación trabajará aislado del módulo de extracción y
procesamiento de datos.

Esto permitirá separar los tipos de acceso, de modo que solo los
dispositivos conectados mediante módulos Arduino puedan modificar la
información de los repositorios en la nube, más la presentación de los
mismos sea mediante acceso web, permitiendo así que la información
tenga más seguridad respecto al acceso vía internet.

4. Identificando las propuestas arquitectónicas

 Usuarios Finales:
-No flexible: El cliente tiene una visión especifica del producto

 Organización durante Desarrollo:

-Flexible: Los desarrolladores tienen control sobre la estructura de
manejo del equipo y el proceso de desarrollo

 Entorno Tecnico:
-Flexible: Hay diversas herramientas disponibles para el desarrollo de
una aplicación web y diversos servicios para facilitar el IoT

 Experiencia arquitectural:
-No Flexible: El equipo de desarrollo esta compuesto de desarrolladores
jóvenes. Los desarrolladores tienen experiencia previa en los conceptos
orientados a objetos y métodos para el desarrollo web.
5. Arboles de Utilidad

Utilidad

(H,H)El sistema debera estar

Disponibilidad Permanencia en la red en linea un 95,00% del
tiempo disponible (24h/dia)

(H,H)La data obtenida en

Rendimiento Tiempo de latencia tiempo real debe ser menor
a 3 segundos

6. Análisis de las propuestas arquitectónicas

Escenario: El sistema deberá estar en línea un
Escenario #: D1.1
95% del tiempo disponible (24h/día)
Atributo de Disponibilidad
Calidad
Entorno Operaciones Normales
Estimulo Petición de acceso Usuario
Respuesta 0.95 de acceso logrado con éxito
Decisión arquitectural Sensivity Tradeoff Risk Nonrisk
Uso de Cliente Servidor – N1
3 capas
Uso de Amazon EC2 para S2 T1 R2
el almacenamiento en la
nube
Uso de Java GlassFish T2 N3
como servidor
Uso de mLab para el S4 R4
almacenamiento de la BD
Razonamiento Valida cada petición al servidor mediante un servicio en web,
de modo que pueda estar activo por mantenimiento externo.
(R2)
En el flujo interno del programa existe el acceso a la BD
mediante conexión a internet lo que podría generar caídas del
sistema, por agente externo (R4)
Cualquier otra falla deberá verse antes del lanzamiento de la
aplicación ya que serian errores de desarrollo.
Diagrama
Arquitectónico Peticiones que no
pueden ser manejadas

Verificación Redireccion de Carga

EC2, mLab

Escenario: La data obtenida en tiempo real debe

Escenario #: R1.1
ser menor a 3 segundos
Atributo de Rendimiento
Calidad
Entorno Operaciones Normales
Estimulo Consulta de estado de Maquinaria
Respuesta Latencia con un tiempo menor a 3 segundos
Decisión arquitectural Sensivity Tradeoff Risk Nonrisk
Contar con Modulos ECP S1 R1
y sensores modulares
Uso de un Broker S2 R2
gratuito
Uso de Amazon EC2 S3 T3 N3
para el almacenamiento
en la nube
Uso de Java GlassFish S4 T4 N4
como servidor
Razonamiento Los modulos envían paquetes de información detectada por
los sensores al servidor que serán recibidas mediante el
bróker en protocolo SSL.(R1)(R2)
El cliente en la pantalla de Estados podrá visualizar la
maquinaria en tiempo real con una latencia no menor a 3
segundos
De haber un problema con los sensores se notificara dicho
error
La disponibilidad estará en riesgo ajeno al sistema ya que es
un servicio de tercero .
Diagrama
Arquitectónico Aplicacion
Cliente
Peticiones de Broker
Estado Mosquitto
Servidor
7. Lluvia de ideas y priorización de escenarios

-Hacer uso del bróker comercial HiveMQ: reduce el tiempo de latencia,

mejorando el atributo de Rendimiento
-Hacer uso de Servicios de Amazon que mejoren la velocidad de respuesta de la
aplicación web, mejorando el atributo de Rendimiento
-Implementar un módulo personalizado por ingenieros eléctricos que cumplan la
función de los módulos ESP y los sensores de actividad de prensas, mejorando
el atributo de Rendimiento.
-Hacer uso de un nivel mayor de los AWS, mejorando el atributo de
Disponibilidad

8. Analizar Aproximaciones Arquitecturales

Escenario: El sistema deberá estar en línea un

Escenario #: D1.1
95% del tiempo disponible (24h/día)
Atributo de Disponibilidad
Calidad
Entorno Operaciones Normales
Estimulo Petición de acceso Usuario
Respuesta 0.95 de acceso logrado con éxito
Decisión arquitectural Sensivity Tradeoff Risk Nonrisk
Uso de Web Sockets N1
Uso de un balanceador S2 T1 R2
de peticiones
Contar con servidores de N3
respaldo
Redireccionamiento de S4 N4
carga
Contratar un servicio S5 T2 N5
especializada en Hosting
de alta velocidad
Razonamiento Valida cada petición al servidor mediante un servicio en web,
de modo que pueda estar activo por mantenimiento externo.
En caso de presentarse fallas se habilitarán los servidores de
respaldos que se encuentren disponibles en menos de 10
minutos a partir de la falla
En caso de no contar con servidores de respaldo se
redireccionará la carga de recepción a los servidores ajenos
que puedan procesarla.

Diagrama
Arquitectónico
Peticiones que no
pueden ser manejadas

Redireccion de Carga

Balanceador de
Peticiones Local
 Escenario: La data obtenida en tiempo real debe
Escenario #: R1.1
ser menor a 3 segundos
Atributo de Rendimiento
Calidad
Entorno Operaciones Normales
Estimulo Consulta de estado de Maquinaria
Respuesta Latencia con un tiempo menor a 3 segundos
Decisión arquitectural Sensivity Tradeoff Risk Nonrisk
Contar con Módulos y S1 N1
sensores fabricados
especialmente para
dicha función
Contratar un bróker S2 T1 R2
comercial
Aumentar las S3 N3
prioridades de
procesamiento en las
funciones relacionadas
Reducir la carga S4 T4 R4
computacional
Razonamiento Los modulos envían paquetes de información que serán
recibidas mediante el bróker en protocolo SSL.
En caso de no contactar con los se mantendrá en espera la
solicitud (tiempo de solicitud menor a 3 segs)
De no presentarse respuesta a la solicitud se establecera
prioridades a las peticiones reduciendo la carga
computacional del mismo
La disponibilidad estará en riesgo dado que el sistema no
cuenta con un canal de soporte propio (R2)

Diagrama
Arquitectónico Conexion
maquinarias-servidor

Verificación Reducir Carga

Computacional

Respuesta

9. Presentacion de Resultados