Práctica 07 - Métodos para Diseñar La Arquitectura

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
“DECANA DE AMÉRICA”
FACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

E.P. INGENIERÍA DE SOFTWARE
ARQUITECTURA DE SOFTWARE
DOCENTE:
HUGO R. CORDERO SÁNCHEZ
PRÁCTICA 07
GRUPO 4
INTEGRANTES:
- Alberto Miranda Anderson Leandro 18200247
- Gonzales Julluni, Alexandra Tania 18200081
- Marcos Valdez Alexander 18200089
- Navarro Ortiz Eduardo 18200279
- Rojas Miñan, Alexis Luis Clemente 18200317
- Valentin Ricaldi David Frank 18200103

-
Lima, Perú
2021 - I
1. Se tiene los siguientes requerimientos para desarrollar un sistema web de encuestas:
- Debe permitir la configuración de encuestas para distintos propósitos, desde cuestionarios
simples y formularios de votación hasta evaluaciones avanzadas con múltiples opciones.
- Las encuestas deben poder personalizarse a nivel visual de distintos colores e imágenes en
las cabeceras y pies de páginas.
- Se deberá poder configurar textos de presentación, instrucciones, notas de ayuda a las
preguntas y despedidas.
- Se debe poder configurar un cronograma de vigencia de las encuestas, de tal forma que se
encuentre vigente hasta determina fecha.
- La encuesta puede tener una o más preguntas, las preguntas pueden están organizadas en
una página cada una o agruparse un número determinado por página o todas en la misma
página.
- Las preguntas pueden ser de respuesta de texto abierta o de respuesta con opciones
seleccionables simple y múltiple. Así misma también podrán ser de respuesta con matriz
de opciones (filas y columnas).
- Se debe poder configurar precedencia en las preguntas, de tal forma que algunas
preguntas aparezcan dependiendo de la opción que se escoge.
- Se debe poder agregar imágenes a las opciones de las preguntas.
- Cuando la encuesta esté configurada debe poder enviar correos electrónicos con la
invitación a los participantes. El envío de los correos se debe poder programar para una
fecha determinada. Se puede hacer varios envíos de correos a los participantes, con la
opción de enviar a los que aún no han respondido.
- Las encuestas se deben poder integrar con el directorio activo de windows para obtener
los usuarios participantes.
- Los resultados de las encuestas se podrán exportar y descargar en Excel.
- Así mismo debe tener una opción para integrarse con Power BI a través de un cubo.
- La interfaz de la encuesta debe ser responsiva de tal forma que se pueda visualizar en web
y en móvil.
- Los tiempos de respuesta deben ser óptimos para soportar en promedio 50 usuarios
concurrentes y 2000 usuarios participantes por encuesta.
- La tecnología a usar debe ser .NET Core que es el estándar de la empresa.
Utilizar ACDM
1. Determinar drivers arquitectónicos

Entrada:
Presentación del proyecto a los stakeholders:
“LimpiaYA” es una empresa relacionada al rubro de venta de productos de limpieza para el

hogar. Esta empresa realiza encuestas web con el objetivo de detectar el comportamiento y
las tendencias de sus clientes. Siendo este, uno de los puntos fuertes de la empresa en relación
con el marketing.
Actualmente, la empresa hace uso de distintas herramientas web como Google Forms, Gmail,
Power BI, etc. Por ello, el proceso de realización de cuestionarios y obtención de resultados
es un tanto tedioso. Ahora que la empresa se encuentra en crecimiento surge la necesidad de
poseer un sistema web de encuestas que permita automatizar y agilizar los procesos
relacionados a estos.
Proceso:
Requerimientos obtenidos:
Requisito Funcional Descripción

Debe permitir la configuración de encuestas para distintos
propósitos, desde cuestionarios simples y formularios de
votación hasta evaluaciones avanzadas con múltiples
Requisito Funcional opciones.
Las encuestas deben poder personalizarse a nivel visual de
distintos colores e imágenes en las cabeceras y pies de
Requisito Funcional páginas.
Se deberá poder configurar textos de presentación,
Requisito Funcional instrucciones, notas de ayuda a las preguntas y despedidas.
Se debe poder configurar un cronograma de vigencia de las
encuestas, de tal forma que se encuentre vigente hasta
Requisito Funcional determinada fecha.
La encuesta puede tener una o más preguntas, las preguntas
pueden estar organizadas en una página cada una o agruparse
un número determinado por página o todas en la misma
Requisito Funcional página.
Las preguntas pueden ser de respuesta de texto abierta o de
respuesta con opciones seleccionables simple y múltiple. Así
mismo también podrán ser de respuesta con matriz de
Requisito Funcional opciones (filas y columnas).
Se debe poder configurar precedencia en las preguntas, de tal
forma que algunas preguntas aparezcan dependiendo de la
Requisito Funcional opción que se escoge.
Se debe poder agregar imágenes a las opciones de las
Requisito Funcional preguntas.
Cuando la encuesta esté configurada debe poder enviar
correos electrónicos con la invitación a los participantes. El
envío de los correos se debe poder programar para una fecha
determinada. Se puede hacer varios envíos de correos a los
participantes, con la opción de enviar a los que aún no han
Requisito Funcional respondido.
Las encuestas se deben poder integrar con el directorio activo
Atributo de calidad - Integración de windows para obtener los usuarios participantes.
Los resultados de las encuestas se podrán exportar y
Requisito Funcional descargar en Excel.
Así mismo debe tener una opción para integrarse con Power
Atributo de calidad - Integración BI a través de un cubo.
La interfaz de la encuesta debe ser responsiva de tal forma
Atributo de calidad - Interoperabilidad que se pueda visualizar en web y en móvil.
Los tiempos de respuesta deben ser óptimos para soportar en
promedio 50 usuarios concurrentes y 2000 usuarios
Atributo de calidad - Escalabilidad participantes por encuesta.
La tecnología a usar debe ser .NET Core que es el estándar
Restricción de la empresa.
Salidas:
Drivers arquitectónicos:
LEYENDA
AC Atributo de calidad
RF Requisito Funcional
REST Restricción
Tipo de driver Descripción
Debe permitir la configuración de encuestas para distintos propósitos,

desde cuestionarios simples y formularios de votación hasta
Driver1-RF01 evaluaciones avanzadas con múltiples opciones.
La encuesta puede tener una o más preguntas, las preguntas pueden

estar organizadas en una página cada una o agruparse un número
Driver2-RF02 determinado por página o todas en la misma página.
Las preguntas pueden ser de respuesta de texto abierta o de respuesta

con opciones seleccionables simple y múltiple. Así mismo también
Driver3-RF02 podrán ser de respuesta con matriz de opciones (filas y columnas)
Cuando la encuesta esté configurada debe poder enviar correos
electrónicos con la invitación a los participantes. El envío de los
correos se debe poder programar para una fecha determinada. Se
puede hacer varios envíos de correos a los participantes, con la opción
Driver4-RF03 de enviar a los que aún no han respondido.
Las encuestas se deben poder integrar con el directorio activo de
Driver5-AC01 windows para obtener los usuarios participantes.
Los resultados de las encuestas se podrán exportar y descargar en
Driver6-RF04 Excel.
Así mismo debe tener una opción para integrarse con Power BI a
Driver7-AC02 través de un cubo.
promedio 50 usuarios concurrentes y 2000 usuarios participantes por
Driver8-AC03 encuesta.
La tecnología a usar debe ser .NET Core que es el estándar de la
Driver9-REST empresa.
2. Establecer el alcance del proyecto

Entrada:
● Drivers de arquitectura
Proceso:
Análisis y refinamiento de drivers arquitectónicos:
Drivers arquitectónicos:
Tipo de driver Descripción Prioridad
Debe permitir la configuración de encuestas para distintos propósitos,

desde cuestionarios simples y formularios de votación hasta
Driver1-RF01 evaluaciones avanzadas con múltiples opciones. Alta
La encuesta puede tener una o más preguntas, las preguntas pueden

estar organizadas en una página cada una o agruparse un número
Driver2-RF02 determinado por página o todas en la misma página. Media
Las preguntas pueden ser de respuesta de texto abierta o de respuesta

con opciones seleccionables simple y múltiple. Así mismo también
Driver3-RF02 podrán ser de respuesta con matriz de opciones (filas y columnas) Media
Cuando la encuesta esté configurada debe poder enviar correos
electrónicos con la invitación a los participantes. El envío de los
correos se debe poder programar para una fecha determinada. Se
puede hacer varios envíos de correos a los participantes, con la opción
Driver4-RF03 de enviar a los que aún no han respondido. Alta
Las encuestas se deben poder integrar con el directorio activo de
Driver5-AC01 windows para obtener los usuarios participantes. Alta
Los resultados de las encuestas se podrán exportar y descargar en
Driver6-RF04 Excel. Media
Así mismo debe tener una opción para integrarse con Power BI a
Driver7-AC02 través de un cubo. Alta
promedio 50 usuarios concurrentes y 2000 usuarios participantes por
Driver8-AC03 encuesta. Alta
La tecnología a usar debe ser .NET Core que es el estándar de la
Driver9-REST empresa. Alta
Creación del plan de proyecto preliminar:
Elementos:
● Creación de la arquitectura nocional
● Definición de actividades
Etapa Descripción de la etapa Consideraciones
1 Determinar drivers arquitectónicos Número de reuniones con el cliente: 2
Tiempo: 1 semana
2 Establecer el alcance del proyecto Drivers totales obtenidos: 9
Tiempo: 1 semana
3 Creación/Refinación de la arquitectura Tamaño del equipo de arquitectura: 5

nocional
Alcance del sistema: Se encargará de
crear, almacenar y exportar encuestas.
Además como plataforma para el llenado
de cuestionarios.
Tiempo estimado: 1 semana
4 Evaluación de la arquitectura Tiempo estimado: 1 semana

5 Comenzar/No comenzar la producción Tiempo estimado: 1 semana
6 Experimentación Número de experimentos estimado: 3
Duración por experimento: 3 días
Experimentos simultáneos: 2
7 Plan de producción Tiempo estimado: 1 semana
● Refinación de la arquitectura
Salidas:
● Drivers actualizados
● Plan de proyecto preliminar terminado
3. Creación/refinamiento de la arquitectura
Entrada:
Proceso:
Establecer el contexto
Diagrama de contexto del sistema de encuestas web ELiYA:
Partición del sistema
Primera partición:
Segunda partición:
Capa de presentación:
Capa de negocio:
Integraciones (servicio de terceros):
Capa de datos:
Tercera partición:
Capa de presentación:
Aplicación web:
Capa de negocio:
Módulo encuestas:
Módulo cuestionarios:
Integraciones (servicio de terceros):
Capa de datos:
No necesita mayor partición
Asignación de responsabilidades
Módulo participantes:
● Crear encuestas
● Enviar correos a participantes
● Generar cubo PowerBI
● Obtener participantes
Módulo cuestionarios:
● Crear preguntas
● Responder preguntas
Documentar decisiones de diseño, responsabilidades de elementos y relaciones
Patrón arquitectónico elegido para el sistema: 3 capas

Responsabilidades de elementos: Módulo participantes y módulo cuestionarios
Relaciones:
● Módulo encuestas: PowerBI, Windows Active Directory, vista personal empresa y
base de datos ELiYA
● Módulo cuestionarios: Vista personal empresa, vista cliente y base de datos ELiYA
Salida:
● Diseño inicial de la arquitectura
4. Evaluación de arquitectura
Entrada:
Diseño inicial de la arquitectura
Proceso:
Reunión entre partes interesadas y el equipo de trabajo:
● Presentación y expectativas
● Revisión de requisitos funcionales de alto nivel, limitaciones y tabla de
caracterización
● Presentación del diseño inicial de arquitectura
● Análisis arquitectónico
Problemas encontrados:
ID problema Contenido Driver afectado
Prob1 No se aprecia el envío de correos electrónicos en la Driver4

arquitectura
Prob2 No se llega a entender el apartado de exportar a Excel Driver6

Prob3 Las flechas que representan las relaciones en el Ninguno
diagrama no están acompañados por texto
Salida:
Lista de problemas descubiertos
5. Comenzar la producción/No comenzar la producción
Entrada:
● Lista de problemas encontrados
Proceso:
Indicaciones sólidas para comenzar la producción:
Indicación ¿Se cumplió?
La arquitectura ha madurado hasta el punto en que los diseñadores No

posteriores están suficientemente restringidos y pueden utilizar la
arquitectura para guiar su diseño
Durante la revisión, el arquitecto pudo explicar cómo respondería el Sí

sistema para los atributos de calidad
No se han descubierto riesgos importantes que pudieran poner en riesgo el Sí

diseño de la arquitectura durante la revisión de los problemas
Indicaciones sólidas para continuar el refinamiento:
El arquitecto no pudo responder a todas las preguntas de sondeo acerca de No

la arquitectura
Hubo respuestas contradictorias a preguntas de sondeo en la arquitectura No
Las partes claves de la arquitectura aún no se han definido No
Se encontraron más de 3 problemas No
Durante la presentación de la arquitectura, el arquitecto tuvo que dibujar No

frecuentemente imágenes complementarias para explicar su arquitectura
Salida:
● Decisión del equipo: Pasar a producción
6. Experimentación
Este paso se obvia si se decide comenzar la producción.
Entrada:
Proceso:
Definición y resultados de experimentos a realizar
Plan de experimento
Elemento Descripción del contenido
ID de experimento EXP1
Responsable Anderson Alberto Miranda

ingeniero
Objetivo Determinar el impacto en la arquitectura causado por no haber

mostrado el envío de correos correctamente
Resultados esperados Impacto menor en la arquitectura no haber mostrado el envío de

correos
Recursos requeridos No es necesario ningún recurso informático
Artefactos Resultados del plan de experimento EXP1
Descripción del Para realizar este experimento, se revisará la documentación del

experimento driver afectado y se generarán escenarios relativos a ello.
Duración Fecha de inicio: 25/08/21

Fecha de fin: 26/08/21
Resultados y Se genera un impacto crítico al no definir correctamente como es el

recomendaciones envío de mensajes. No se puede saber a quiénes se envía y como
verificar si son recibidos.
Salida:
Resultados obtenidos de los experimentos
7. Plan de producción
Entrada:
- Diseño de la arquitectura
Proceso:
Estimar el tiempo que tomará construir cada elemento de la arquitectura:
Formulario de estimación de elementos
Nombre del sistema ELiYA
Nombre del elemento Crear encuestas

Ingeniero responsable Eduardo Navarro Ortiz
Tiempo estimado 3 semanas
Fecha de estimación 27/08/2021
Justificación (opcional)
Nombre del elemento Enviar correo a participantes
Ingeniero responsable Alexandra Gonzales Julluni
Nombre del elemento Generar cubo PowerBI
Ingeniero responsable David Frank Valentin
Nombre del elemento Obtener participantes
Ingeniero responsable Anderson Alberto Miranda
Nombre del elemento Exportar a Excel
Ingeniero responsable Alexander Marcos Junior
Nombre del elemento Crear preguntas
Ingeniero responsable Alexis Rojas Miñan
Nombre del elemento Responder preguntas
Crear un cronograma de producción:
Ítem Duración
Diseño de elementos 1 semana

Revisión de elementos 1 semana
Construcción de elementos 2 semanas
Integración de elementos 1 semana
Despliegue 1 semana
Prueba de elementos 1 semana
Prueba de sistemas 1 semana
Prueba operacional 1 semana
Salida:
- Cronograma de producción
2. Se tienen los siguientes requerimientos para un portal web de búsqueda y separación de
visitas para proyectos inmobiliarios:
- Registro y mantenimiento de empresas constructoras
- Mantenimiento y registro de proyectos inmobiliarios por las constructoras
- Carga de imágenes para los proyectos inmobiliarios por las constructoras
- Gestionar los vendedores inmobiliarios por proyecto
- Registro de clientes interesados, olvidé clave y modificación de datos personales
- Mantenimiento de clientes interesados
- Búsquedas de proyectos inmobiliarios por distintas características
- Ver detalle y fotos de proyectos inmobiliario
- Registro de solicitud de visita por interesado a un proyecto inmobiliario
- Gestión de visitas para los proyectos inmobiliarios
- Consulta del estado de una visita
- Gestión de usuarios administradores
- Implementación de portales para acceso de constructoras, vendedores, clientes interesados y
administradores.
- La página debe ser fácil de usar e intuitiva.
- El proyecto debe realizarse en no más de 3 meses
- La plataforma tecnológica debe ser desplegada íntegramente en la nube
Utilice ADD
Descripción Funcional
No se encontraron restricciones de capacidad.

1. Confirmar que se tiene información suficiente de los drivers
arquitectónicos.
Tabla con los drivers arquitectónicos identificados:

Driver Descripción Requerimiento Tipo
Driver1-RF01 Registro y mantenimiento de empresas REQ1 Funcional

constructoras
Driver2-RF02 Mantenimiento y registro de proyectos REQ2 Funcional

inmobiliarios por las constructoras
Driver3-RF03 Gestionar los vendedores inmobiliarios por REQ4 Funcional

proyecto
Driver4-RF04 Registro de clientes interesados, olvidé clave REQ5 Funcional

y modificación de datos personales
Driver5-RF05 Mantenimiento de clientes interesados REQ6 Funcional
Driver6-RF06 Búsquedas de proyectos inmobiliarios por REQ7 Funcional

distintas características
Driver7-RF07 Registro de solicitud de visita por interesado REQ9 Funcional

a un proyecto inmobiliario
Driver8-RF08 Gestión de visitas para los proyectos REQ10 Funcional

inmobiliarios
Driver9-RF09 Gestión de usuarios administradores REQ12 Funcional
Implementación de portales para acceso de

Driver10-RF10 constructoras, vendedores, clientes REQ13 Funcional
interesados y administradores.
Driver11-REST11 El proyecto debe realizarse en no más de 3 Restricción de

REQ15
meses Implementación
Driver12-AC12 La plataforma tecnológica debe ser REQ16

desplegada íntegramente en la nube Soportabilidad
2. Elegir un elemento del sistema a descomponer

3. Identificar los drivers arquitectónicos asociados al elemento
Número Elemento Asignación de driver arquitectónico Prioridad
1 Portal Web Driver10-RF010 Baja
2 Cliente Driver4-RF04, Driver5-RF05 Baja
3 Empresas Constructoras Driver1-RF01 Alta
4 Vendedores Driver1-RF01 Alta
5 Proyectos Inmobiliarios Driver1-RF01 Alta
6 Base de Datos NA Alta
7 Controlador NA Alta
8 Data Access Object NA Alta
4. Elegir un concepto de diseño en relación con el elemento y los drivers

elegidos.
Número Elemento Driver Concepto de Diseño
1 Portal Web Driver10-RF010 Patrón Arquitectónico MVC
2 Cliente Driver4-RF04, Driver5-RF05 Patrón Arquitectónico MVC
3 Empresas Constructoras Driver1-RF01 Patrón Arquitectónico MVC
4 Vendedores Driver1-RF01 Patrón Arquitectónico MVC
5 Proyectos Inmobiliarios Driver1-RF01 Patrón Arquitectónico MVC
6 Base de Datos NA Patrón Arquitectónico DAO
7 Controlador NA Patrón Arquitectónico MVC
8 Data Access Object NA Patrón Arquitectónico DAO
5. Instanciar los elementos y asignar responsabilidades
Número Elemento Responsabilidad

1 Portal Web Recibe peticiones de clientes, empresas constructoras,
vendedores y proyectos inmobiliarios.
2 Cliente Solicita peticiones al portal web acerca de clientes

registrados.
3 Empresas Constructoras Solicita peticiones al portal web acerca de empresas

constructoras registradas.
4 Vendedores Solicita peticiones al portal web acerca de vendedores

registrados.
5 Proyectos Inmobiliarios Solicita peticiones al portal web acerca de proyectos

inmobiliarios registrados.
6 Base de Datos Almacena datos de clientes, empresas constructoras,

7 Controlador Sirve de interfaz entre la vista y el modelo.
8 Data Transfer Object Sirve de interfaz entre el modelo y la base de datos
6. Definir interfaces para los elementos instanciados
Número Elemento Interfaz

1 Portal Web Controller (Peticiones HTTP)
2 Cliente -
3 Empresas Constructoras Controller (Peticiones HTTP) y DAO
4 Vendedores Controller (Peticiones HTTP) y DAO
5 Proyectos Inmobiliarios Controller (Peticiones HTTP) y DAO
6 Base de Datos DAO: Interfaz común entre la aplicación y la

base de datos
7 Controlador -
8 Data Access Object -
7. Verificar y refinar requerimientos y transformarlos en restricciones

de los elementos instanciados.
Restricciones de los Drivers Arquitectónicos

REQ15

Todos los elementos pasan a estar en la nube debido al driver arquitectónico

Driver12-AC12.
8. Repetir los pasos anteriores.
Repetimos el paso para pasar a descomponer cliente

1 Portal Web Driver10-RF010 Baja
2 Cliente Driver4-RF04, Driver5-RF05 Alta
9 Visitas Driver6-RF06, Driver7-RF07, Alta

Driver8-RF08

elegidos.
9 Visitas Driver6-RF06, Driver7-RF07, Patrón Arquitectónico MVC

Driver8-RF08


registrados.


registrados.


9 Visitas Solicita peticiones al portal web acerca de visitas

registradas.

2 Cliente Controller (Peticiones HTTP) y DAO

base de datos
7 Controlador -
9 Visitas Controller (Peticiones HTTP) y DAO


REQ15

Todos los elementos incluyendo los nuevos elementos de Cliente pasan a estar
en la nube debido al driver arquitectónico Driver12-AC12.

Repetimos el paso para pasar a descomponer cliente
1 Portal Web Driver10-RF010 Alta
2 Cliente Driver4-RF04, Driver5-RF05 Alta
9 Visitas Driver6-RF06, Driver7-RF07, Alta

Driver8-RF08
10 Usuarios Administradores Driver9-RF09 Alta
11 Authentication Middleware Driver10-RF010 Alta

elegidos.

9 Visitas Driver6-RF06, Driver7-RF07, Patrón Arquitectónico MVC

Driver8-RF08
10 Usuarios Driver9-RF09 Patrón Arquitectónico MVC

Administradores
11 Authentication Driver10-RF010 COT: Middlesware

Middleware


registrados.


registrados.


9 Visitas Solicita peticiones al portal web acerca de visitas

registradas.
10 Usuarios Administradores Solicita peticiones al portal web acerca de usuarios

administradores registrados.
11 Authentication Middleware Middleware de autenticación.

2 Cliente Controller (Peticiones HTTP) y DAO

base de datos
7 Controlador -
9 Visitas Controller (Peticiones HTTP) y DAO
10 Usuarios Administradores Controller (Peticiones HTTP) y DAO
11 Authentication Middleware -


REQ15

Todos los elementos incluyendo los nuevos elementos de Usuarios

Administrador y del middleware de autenticación pasan a estar en la nube
debido al driver arquitectónico Driver12-AC12.
3. El sistema de tickets que permite la gestión de
incidencias a nivel técnico.
● El sistema debe permitir organizar la forma de atender los casos de incidencias de los usuarios
de acuerdo con sus prioridades.
● El sistema debe ofrecer un mecanismo para el registro y seguimiento adecuado de las
incidencias que se presentan en las sedes de sus clientes.
● Las incidencias pueden ser resueltas de manera remota o de manera presencial por los
técnicos.
● Se debe contar con técnicos en primera línea (soporte remoto), segunda línea (soporte
presencial) y tercera línea (especialista).
● Registrar y permitir el seguimiento de problemas
● Gestionar el Inventario de Hardware y Software
● Gestionar el historial de incidencias
● Asignación de las incidencias y problemas de TI
● Notificación por correo electrónico totalmente configurable
● Permite ver gráficos estadísticos e informes
● Permite un flujo de gestión escalable de un grupo de técnico a otro
● 1000 transacciones de solicitudes por segundo.
● 100% disponibilidad en horario de oficina, 5 días a la semana.
● Mecanismo de seguridad en caso de suplantación de identidad.
● Interface amigable e intuitiva para los usuarios
Método de definición de arquitecturas

1. Consolidar las entradas (requerimientos/drivers)
Código Requerimiento Tipo
Debe permitir organizar la forma de atender los casos de

R01 Funcional
incidencias de los usuarios de acuerdo a las prioridades.
Debe ofrecer un mecanismo para el registro y

R02 seguimiento adecuado de las incidencias para las sedes Funcional
de sus clientes.
Las incidencias pueden ser resueltas de manera remota o

R03 Escalabilidad
presencial.
Se debe contar con técnicos: en primera línea, en

R04 Soportabilidad
segunda línea y en tercera línea.
R06 Gestionar el inventario de Hardware y Software. Funcional
R07 Gestionar el historial de incidencias. Funcional
R08 Asignación de las incidencias y problemas de TI. Funcional
Notificación por correo electrónico totalmente

R09 Funcional
configurable.
R10 Permite ver gráficos estadísticos e informes. Funcional
Permite un flujo de gestión escalable de un grupo de

R11 Escalabilidad
técnicos a otro.
R12 1000 transacciones de solicitudes por segundo. Rendimiento
100% disponibilidad en horario de oficina, 5 días a la

R13 Disponibilidad
semana.
R14 Mecanismo de seguridad en caso de suplantación de Seguridad

identidad.
R15 Interface amigable e intuitiva para los usuarios Usabilidad
COD. DRIVER ARQUITECTÓNICO REQ. NRO. TIPO
Debe ofrecer un mecanismo para el

registro y seguimiento adecuado de
D01 R02, R05, R07 Funcional
las incidencias para las sedes de sus
clientes.
Las incidencias pueden ser resueltas

D02 R03, R11 Escalabilidad
de manera remota o presencial.
Se debe contar con técnicos: en

D03 primera línea, en segunda línea y en R04 Soportabilidad
tercera línea.
Gestionar el inventario de Hardware y

D04 R06 Funcional
Software.
Asignación de las incidencias y

D05 R08 Funcional
problemas de TI.
1000 transacciones de solicitudes por

D06 R12 Rendimiento
segundo.
100% disponibilidad en horario de

D07 R13 Disponibilidad
oficina, 5 días a la semana.
Mecanismo de seguridad en caso de

D08 R14 Seguridad
suplantación de identidad.
Interface amigable e intuitiva para los

D09 R15 Usabilidad
usuarios
2. Identificar un conjunto de escenarios de requerimientos más importantes.
Escenario de calidad Las incidencias pueden ser resueltas de manera remota o

presencial
Atributo de calidad Escalabilidad
Fuente El usuario
Estímulo Llega un nuevo incidente

Entorno Se encuentra de manera remota o presencial
Artefacto Sistema de tickets
Respuesta Se atiende la incidencia de manera exitosa
Medida de respuesta Debe permitir la atención tanto de manera presencial como remota
Escenario de calidad Se debe contar con técnicos: en primera línea, en segunda línea y
en tercera línea.
Atributo de calidad Soportabilidad
Fuente Usuario
Estímulo Nueva solicitud de atención al nivel correspondiente
Entorno Normal
Respuesta Atención de un técnico de primera, segunda o tercera línea
Medida de respuesta Control del número de técnicos disponibles para atender una
solicitud
Escenario de calidad 1000 transacciones de solicitudes por segundo.
Atributo de calidad Rendimiento
Fuente Usuario
Estímulo Realizar una nueva transacción
Entorno Con alta carga de transacciones
Respuesta Deberá de responder con éxito a todas las transacciones
Medida de respuesta Se evaluará que todas las transacciones no hayan demorado más
de 1 segundo en responder
Escenario de calidad 100% disponibilidad en horario de oficina, 5 días a la semana.
Atributo de calidad Disponibilidad

Fuente Usuarios del sistema
Estímulo Realización de transacciones en el sistema
Entorno Normal
Respuesta Atención en el horario de oficina los 5 dias de la semana
Medida de respuesta Funcionamiento continuo del sistema
Escenario de calidad Mecanismo de seguridad en caso de suplantación de identidad.
Atributo de calidad Seguridad
Fuente Usuario
Estímulo Intento de suplantación de identidad
Entorno En todo los escenarios
Artefacto Autenticación del usuario
Respuesta Impedir la realización de transacciones
Medida de respuesta Notificación al usuario y bloquear el acceso
Escenario de calidad Interface amigable e intuitiva para los usuarios
Atributo de calidad Usabilidad
Fuente Usuario
Estímulo El usuario interacciona con la interfaz
Entorno En todos los casos
Artefacto Interfaz gráfica del Sistema de tickets
Respuesta Ofrecer una experiencia amigable e intuitiva
Medida de respuesta Número de pasos y tiempo que demora para realizar una
transacción
3. Identificar estilos arquitectónicos relevantes

Las posibles arquitecturas que se pueden implementar a partir del análisis realizado son:
● Arquitectura orientada a eventos: debido a que se requiere de alto rendimiento para realizar
las transacciones y permite la integración de nuevos módulos que se puedan integrar al bus de
servicio y a su vez manejar las llamadas que se realizan
Arquitectura orientada a eventos
● Microservicios: debido a que maneja independencia entre los servicios que conforman la
aplicación, permite la adición de nuevos servicios de acuerdo a la demanda que se presente.
Arquitectura de microservicios
● Arquitectura por capas: si se implementa correctamente puede contribuir a la seguridad de la

aplicación ya que se debería de pasar por una capa de autenticación para permitir que se
realicen las funcionalidades del sistema. También se puede utilizar para controlar que el
sistema esté disponible según el horario indicado.
Arquitectura por capas
4. Producir una arquitectura candidata

Se evaluó que el sistema se compondrá por diferentes módulos según la funcionalidad que se
desempeñe, siendo la capa de interfaz de usuario la que comunique la lógica del negocio con los
usuarios finales. En la lógica de negocio se encontrará definido una capa de seguridad que sera
transversal a todos los demás módulos indicando que debe de realizarse una consulta antes de cada
llamada a otro servicio.
Sistema de tickets
5. Explorar opciones arquitectónicas
Se especificó cómo se iba a componer la aplicación de forma interna mediante llamadas a servicios
rest debido a la necesidad de comunicación remota y que sea menor a un segundo. A su vez se
muestra que las interfaces tendrán servicios para poder mostrar la información que se consultaran
desde la parte del negocio.
Sistema de tickets
Se muestra una solución para que la aplicación pueda escalar de forma horizontal mediante la
instancia en dos servidores de la lógica de negocio y la implementación de load balancer para
comunicar las vistas de los usuarios con la información que se encuentre almacenada en la base de
datos.
Sistema de tickets
4.Sistema de toma de pedidos móvil:
- Poder reenviar los pedidos pendientes desde el móvil que no pudieron ser enviados por
falta de cobertura
- Mostrar indicadores de eficiencia del usuario, como son: tiempo promedio de cada
pedido, porcentaje de eficiencia y monto total de pedidos
- Se necesita consultar si hay stock o no para un producto a partir del nombre o código del
producto
- Se necesita consultar los pedidos ingresados y su detalle a partir de la fecha de creación
del pedido
- Se necesita realizar Pedidos desde el dispositivo móvil
- Se necesita realizar el canje productos desde el dispositivo móvil
- Se necesita realizar devolución de productos desde el dispositivo móvil
- Se necesita realizar cobranzas desde el dispositivo móvil
- Realizar el proyecto para dispositivos con sistema operativo Android
- Realizar el proyecto para la plataforma Web
- El usuario so lo podrá realizar tareas que le correspondan a su perfil
- En los dispositivos móviles debe permitir concluir las tareas a pesar de que no exista
cobertura.
- Se necesita ingresar nuevos clientes al sistema.
- Se necesita ingresar y configurar usuarios del sistema.
- Mantener logs de errores y de performance
- Se necesita crear nuevas cobranzas hechas por un vendedor aun cliente.
- Se necesita crear nuevos pedidos, hechos por un vendedor a un cliente.
- Las transacciones que se realizan desde los dispositivos móviles deben ser encriptadas
- El sistema debe permitir procesar 3 pedidos por minuto
- Tener una tabla de auditoría para depuración de datos
- El sistema debe estar disponible 95 % anual para atender los pedidos
Utilizar ACDM
ACDM:
Es un modelo que está hecho para adaptarse a los procesos internos de una empresa y se enfoca principalmente
en crear la Arquitectura de Software a través de una práctica estándar
Etapas de ACDM:
Etapa 1: Establecer los drivers arquitectónicos
Etapa 2: Establecer alcance del proyecto

período de
Etapa 3: crear / perfeccionar la arquitectura
incertidumbre
Etapa 4: Revisión de la arquitectura
Etapa 5: decisión de entrar / o no en producción

Planeación y ejecución de experimentos
Etapa 6: Refinamiento de arquitectura
Etapa 7: Planeación de producción

período de certeza
Etapa 8: Producción
Etapa 1: Establecer los drivers arquitectónicos

Se utilizó el método para analizar los drivers arquitectónicos
https://docs.google.com/spreadsheets/d/1p9uFWBBUqC2MHz8X3GU-
WS3vUYrZXz3w4j__LkwC2_Q/edit#gid=614442294
Tabla de drivers arquitectonicos

COD Driver arquitectonico REQ. NRO. TIPO
Poder reenviar los
pedidos pendientes desde
D - 01 el móvil que no pudieron RQ - 12 Funcional
ser enviados por falta de
cobertura
Mostrar indicadores de
eficiencia del usuario,
como son: tiempo
D - 02 promedio de cada CUS12 Funcional
pedido, porcentaje de
eficiencia y monto total
de pedidos
Se necesita crear
pedidos, crear cobranzas,
consultar stock y
consultar los pedidos
D - 03 CUS03,CUS05, CUS07, CUS11 Funcional
ingresados y su detalle a
partir de la fecha de
creación del pedido a
través de la web
Se necesita realizar
Pedidos, canje,
D - 04 devolución y cobranzas CUS04, CUS09, CUS10,CUS06 Funcional
desde el dispositivo
móvil
Realizar el proyecto para
D - 05 dispositivos con sistema RQ - 09 Restricción técnica
operativo Android
Realizar el proyecto para Drivers de restricciones:No
D - 06 RQ - 10
la plataforma Web funcional
Se necesita ingresar
D - 07 nuevos clientes al CUS02 Funcional
sistema
Se necesita ingresar y
D - 08 configurar usuarios del CUS01 Funcional
sistema.
Mantener logs de errores
D - 09 RQ - 15 Atributos de calidad: performance
y de performance
Las transacciones que se
realizan desde los Atributo de calidad:
D - 10 RQ - 18
dispositivos móviles Seguridad
deben ser encriptadas
El sistema debe permitir
Atributo de calidad:
D - 11 procesar 3 pedidos por RQ - 19
Performance
minuto
Tener una tabla de
Atributo de calidad:
D - 12 auditoría para depuración RQ - 20
Seguridad
de datos
El sistema debe estar
disponible 95 % anual
para atender los pedidos Atributo de calidad:
D - 13 RQ - 21
y cuando no hay Disponibilidad
cobertura se permite
concluir tareas
Riesgos arquitectónicos:
-Falta de cobertura
-Robo de información bancaria
-Errores en el sistema
-Datos corruptos en la bd
Etapa 2: Establecer alcance del proyecto
Entrada:
● Drivers de arquitectura
Proceso:
Descripción general del proyecto: El sistema consta de la integración de un sistema web y un aplicativo móvil
para realizar pedidos con el fin de impulsar mayores transacciones de ventas de productos, el sistema debe tener
un alto rendimiento, disponibilidad además debe proteger los datos de los clientes.
Análisis y refinamiento de drivers arquitectónicos:

Caracterización y priorización de atributos
Aquellos escenarios de atributos que califiquen una importancia alta y una dificultad alta serán escenarios de
máxima prioridad para que el equipo se concentre en las etapas posteriores.
Calidad Atributo
Atributo Caracterización Escenarios de atributos Clasificación importancia Dificultad
Al ocurrir un error Log
Analyzer recopila datos de
registro para obtener mayor
Mantener logs de información acerca del
Disponibi errores y de rendimiento y disponibilidad
lidad performance del sistema Bajo Bajo
Cuando no hay cobertura
se permite concluir tareas
Capacidad para y mantener los pedidos para
Disponibi anticipar un fallo ser enviados después desde
lidad y mantener la data el móvil. Elevado Elevado
A mayor peticiones por
minuto el sistema debe
escalar su base de datos
añadiendo más
instancias o nodos a la base
Posibilidad de de datos.Si la
procesar en promedio demanda cae, los recursos
3 pedidos por adicionales se pueden
minuto, con un pico cerrar limpiamente y
Rendimie de rendimiento desasignar.
nto mayor Elevado Elevado
Una falla de hardware hace
que el sistema
operativo se "cuelgue"
durante las
operaciones de ventas. El
defecto se
detecta al contar con 3
nodos, el sistema continúa
su funcionamiento.
Capacidad para El sistema debe estar
anticipar y disponible
Disponibi recuperarse del 95 % anual para atender los
lidad fracaso pedidos. Elevado Medio
La base de datos tiene
funciones de retener
datos del acceso a los
registros,
detectar e informar sobre
actividades
Tener una tabla de sospechosas y
auditoría para potencialmente maliciosas.
Seguridad depurar datos Recopila registros de Bajo Bajo
auditoría almacenados
en las pistas de auditoría de
las bases de
datos de destino y el lote
seleccionados
copia en lotes los datos en
su propia tabla
de auditoría.
Al solicitar una conexión

segura, el navegador
web crea una clave de sesión
Capacidad para que encripta las
encriptar comunicaciones entre el
Seguridad transacciones cliente y servidor Medio Medio
Clarificación y cuantificación
Asimismo, cada requisito funcional
debe describir claramente
Qué se necesita
• qué partes interesadas lo necesitan
• cuánta (funcionalidad) se necesita
• que tan urgentemente se necesita
• qué tan probable es que cambie y qué tan rápido
Para esto se puede hacer uso de las historias de usuario
https://docs.google.com/spreadsheets/d/1p9uFWBBUqC2MHz8X3GU-
WS3vUYrZXz3w4j__LkwC2_Q/edit#gid=1644135145
Definición de restricciones:
Tipo de
restricción Restricción Impacto Flexibilidad
El aplicativo es para
dispositivos con
sistema operativo
Técnico Android - No flexible
El sistema es para la
Técnico plataforma - No flexible
Web
Programátic El sistema debe estar

o listo para
(calendario) funcionar en 6 meses Algunos flexibles
Creación del plan de proyecto preliminar:
Elementos:
● Creación de la arquitectura nocional
● Definición de actividades
Etapa Descripción de la etapa Consideraciones
1 Determinar drivers arquitectónicos Número de reuniones con el cliente: 2
Tiempo: 1 semana
2 Establecer el alcance del proyecto Drivers totales obtenidos: 13
Tiempo: 1 semana
3 Creación/Refinación de la arquitectura Tamaño del equipo de arquitectura: 5

nocional
Alcance del sistema: Se encargará de
crear pedidos, crear cobranzas, consultar
pedidos, devolución productos, canje de
productos.
4 Evaluación de la arquitectura Tiempo estimado: 1 semana
5 Comenzar/No comenzar la producción Tiempo estimado: 1 semana
6 Experimentación Número de experimentos estimado: 3
Duración por experimento: 3 días
Experimentos simultáneos: 2

7 Plan de producción Tiempo estimado: 1 semana
● Refinación de la arquitectura
Salidas:
Etapa 3: crear la arquitectura inicial

Entrada:
Proceso:
Establecer el contexto
Diagrama de contexto del sistema de pedidos web y móvil Pedidos+:
Partición del sistema con base en el contexto

Primera partición:asegura la disponibilidad
Segunda partición: asegura el rendimiento y disponibilidad
En lugar de compartir un mismo almacenamiento, se hace un escalamiento horizontal en las base de datos,
además la bd se encuentra en la nube
3ra partición
Cuarta partición:
Módulo reportes:
● indicadores de eficiencia
Módulo ventas:
● ingresar clientes
● crear pedidos
● crear cobranzas
● consultar pedidos
● consultar stock
Módulo pedidos:
● crear pedidos
● crear cobranzas
● consultar pedidos
● devolución productos
● canje de productos
Documentar decisiones de diseño, responsabilidades de elementos y relaciones
Patrón arquitectónico elegido para el sistema: capas

Responsabilidades de elementos: Módulo reportes, módulo ventas y módulo pedidos
Otros elementos: Vista personal empresa, vista cliente y base de datos
Salida:
Salida:
● Diseño inicial de la arquitectura
Etapa 4: Evaluación de arquitectura
Entrada:
Proceso:
Reunión entre partes interesadas y el equipo de trabajo:
● Presentación y expectativas
● Revisión de requisitos funcionales de alto nivel, limitaciones y tabla de
caracterización
● Presentación del diseño inicial de arquitectura
● Análisis arquitectónico
Problemas encontrados:
ID problema Contenido Driver afectado
Prob1 No se aprecian todos los submódulos del módulo Driver3

ventas
Prob2 No se aprecian todos los submódulos del módulo Driver4

pedidos
Salida:
Lista de problemas descubiertos
Etapa 5: Comenzar la producción/No comenzar la producción
Entrada:
Proceso:
Indicaciones sólidas para comenzar la producción:
La arquitectura ha madurado hasta el punto en que los diseñadores No

posteriores están suficientemente restringidos y pueden utilizar la
arquitectura para guiar su diseño
Durante la revisión, el arquitecto pudo explicar cómo respondería el Sí

sistema para los atributos de calidad
No se han descubierto riesgos importantes que pudieran poner en riesgo el Sí

diseño de la arquitectura durante la revisión de los problemas
Indicaciones sólidas para continuar el refinamiento:
El arquitecto no pudo responder a todas las preguntas de sondeo acerca de No

la arquitectura
Hubo respuestas contradictorias a preguntas de sondeo en la arquitectura No
Las partes claves de la arquitectura aún no se han definido Si
Se encontraron más de 3 problemas No
Durante la presentación de la arquitectura, el arquitecto tuvo que dibujar No

frecuentemente imágenes complementarias para explicar su arquitectura
Salida:
● Decisión del equipo: Pasar a producción
Etapa 6: Experimentación
Este paso se obvia si se decide comenzar la producción.
Entrada:
Proceso:
Definición y resultados de experimentos a realizar
Plan de experimento
Elemento Descripción del contenido
ID de experimento EXP1
Responsable Anderson Alberto Miranda

ingeniero
Objetivo Determinar el impacto en la arquitectura causado por no haber

considerado el volumen de datos
Resultados esperados Fallo de la aplicación-> gran impacto
Recursos requeridos No es necesario ningún recurso informático
Artefactos Resultados del plan de experimento EXP1
Descripción del Para realizar este experimento, se revisará la documentación del

experimento driver afectado y se generarán escenarios relativos a ello.
Duración Fecha de inicio: 25/08/21

Fecha de fin: 26/08/21
Resultados y Se genera un impacto crítico al haber gran volumen de

recomendaciones transacciones y contar con una única base de datos limitada en
capacidad
Salida:
Resultados obtenidos de los experimentos
1. Plan de producción
Entrada:
- Diseño de la arquitectura
Proceso:
Estimar el tiempo que tomará construir cada elemento de la arquitectura:
Nombre del sistema Pedidos+
Nombre del elemento Crear pedidos
Ingeniero responsable Eduardo Navarro Ortiz
Nombre del elemento Crear Cobranzas
Ingeniero responsable Alexandra Gonzales Julluni
Nombre del elemento Generar cubo PowerBI
Ingeniero responsable David Frank Valentin
Nombre del elemento Devolución de productos

Ingeniero responsable Anderson Alberto Miranda
Tiempo estimado 1 semana
Nombre del elemento Canje de productos
Ingeniero responsable Alexander Marcos Junior
Tiempo estimado 1 semana
Nombre del elemento Ingresar clientes
Nombre del elemento Consultar stock y pedidos
Crear un cronograma de producción:
Salida:
- Cronograma de producción
Problema 5
Sistema de asistencia social para la municipalidad:
- Permitir el registro de exámenes médicos de diferentes tipos: examen médico, exámen

odontológico y examen de laboratorio (Análisis Serológico y Heces según la condición de la
ocupación del paciente).
- Emisión del carnet de sanidad, con la posibilidad de tomar foto o adjuntar foto existente.
- El sistema debe permitir actualizar el resultado de los diferentes exámenes, que son
diferentes según el tipo.
- Permitir el registro de solicitudes pre nupcial. En caso de ser nuevo el sistema requerirá el
ingreso de los datos personales de los cónyuges (Nombres, Apellidos, Fecha de
Nacimiento, Documento de Identidad, Lugar de residencia actual).
- Permitir el registro de los datos de los novios. El sistema mostrara los datos de los
conyugues y a su vez validara que los cónyuges estén aptos para ser registrados como
novios usando los datos de los exámenes de ETS/VIH.
- Permitir la emisión del certificado pre nupcial a solicitud.
- La aplicación móvil de consulta de la municipalidad, deberá considerar búsquedas de
doctores por: fechas y horas de disponibilidad, por especialidad. Se deberá presentar
información completa del doctor seleccionado, sus horarios, sus especialidades
- La aplicación móvil deberá considerar búsquedas de exámenes médicos: por especialidad,
por categorías y subcategorías, por horario de atención y especialidad. Se deberá
presentar información completa del examen seleccionado, costos, días de atención,
restricciones, tiempos de atención
- El sistema debe permitir consultar el estado en el que se encuentra un examen de
laboratorio (registrado, en proceso, con resultados) y sus resultados en archivos digitales.
- El sistema debe permitir consultar el estado del carnet sanitario para el usuario, deberá
mostrar al usuario si su carnet aún está vigente o en su defecto si debe ser renovado.
- Generación de Reportes Estadísticos Detallados y Consolidados. Reporte de Indicadores.
- El sistema debe ser capaz de atender al menos 10 usuarios concurrentes internos
(aplicación web en la red local).
- La aplicación debe contar con bitácoras de trazabilidad y errores, debe permitir identificar:
usuario que ejecuto la acción, fecha y hora, acción, mensaje de error y punto de caída en
el código.
- Toda la información de los clientes debe ser almacenada en una base de datos
- La plataforma estándar para desarrollo de software de la municipalidad es Java 7 sobre
PostgreSQL 5.3 y sistemas operativos Linux Ubuntu Server 14.04
- La aplicación debe estar orientada para personas entre 18 a 65 años de edad, no se
consideran funcionalidades de soporte de personas con discapacidades.
- La aplicación Web se debe ver de forma correcta y acomodarse apropiadamente en
móviles de 4’’-5’’ y tabletas de 7’’-10’’
- Todas las tablas del sistema deben tener los siguientes campos de auditoría: usuario de
creación, fecha de creación, usuario de modificación y fecha de modificación.
- El aplicativo web debe responder al usuario en menos de 2 segundos en red local.
- El aplicativo móvil debe responder al usuario en menos de 10 segundos
Tipo de Req.
Descripción Tipo
driver Nro.
Driver1- Permitir el registro de exámenes médicos de diferentes tipos:

REQ01 Funcional
RF01 examen médico, examen odontológico y examen de laboratorio
Driver2- Emitir el carnet de sanidad, con la posibilidad de tomar foto o
REQ02 Funcional
RF02 adjuntar foto existente.
Permitir el registro de solicitudes pre nupcial. En caso de ser nuevo
Driver3- el sistema requerirá el ingreso de los datos personales de los REQ04 Funcional
RF03 conyugues
Permitir el registro de los datos de los novios. El sistema mostrara
los datos de los conyugues y a su vez validara que los conyugues
REQ05 Funcional
Driver4- estén aptos para ser registrados como novios usando los datos de los
RF04 exámenes de ETS/VIH.
Driver5-
REQ06 Funcional
RF05 Permitir la emisión del certificado pre nupcial a solicitud.
Considerar búsquedas de doctores por: fechas y horas de
Driver6- disponibilidad, por especialidad. Se deberá presentar información REQ07 Funcional
RF06 completa del doctor seleccionado, sus horarios, sus especialidades
Considerar búsquedas de exámenes médicos: por especialidad, por
categorías y subcategorías, por horario de atención y especialidad.
Driver7- REQ08 Funcional
Se deberá presentar información completa del examen seleccionado,
RF07 costos, días de atención, restricciones, tiempos de atención
Driver8- Generar Reportes Estadísticos Detallados y Consolidados. Reporte
REQ11 Funcional
RF08 de Indicadores.
Driver9- Atender al menos 10 usuarios concurrentes internos (aplicación web
REQ12 Desempeño
AC01 en la red local).
Contar con bitácoras de trazabilidad y errores, debe permitir
Driver10- identificar: usuario que ejecutó la acción, fecha y hora, acción, REQ13 Soporte
AC02 mensaje de error y punto de caída en el código.
Driver11- REQ14 Funcional

RF09 Almacenar la información de los clientes
Restricción
La plataforma estándar para desarrollo de software de la de
REQ15
Driver11- municipalidad es Java 7 sobre PostgreSQL 5.3 y sistemas operativos implementaci
REST01 Linux Ubuntu Server 14.04 ón
La aplicación debe estar orientada para personas entre 18 a 65 años
Restricción
Driver11- de edad, no se consideran funcionalidades de soporte de personas REQ16
de diseño
REST02 con discapacidades.
Driver10- La aplicación Web se debe ver de forma correcta y acomodarse
REQ17 Usabilidad
AC03 apropiadamente en móviles de 4’’-5’’ y tabletas de 7’’-10’’
Todas las tablas del sistema deben tener los siguientes campos de
Restricción
Driver11- auditoría: usuario de creación, fecha de creación, usuario de REQ18
de diseño
REST03 modificación y fecha de modificación.
Driver10- El aplicativo web debe responder al usuario en menos de 2 segundos
REQ19 Desempeño
AC04 en red local.
Driver10- El aplicativo móvil debe responder al usuario en menos de 10
REQ20 Desempeño
AC05 segundos
1. Confirmar que se tiene información suficiente de los drivers arquitectónicos.
Tipo de
Descripción Req. Nro. Prioridad
driver
Driver1- Permitir el registro de exámenes médicos de diferentes tipos: examen

REQ01 Media
RF01 médico, exámen odontológico y examen de laboratorio
Driver2- Emitir el carnet de sanidad, con la posibilidad de tomar foto o adjuntar
REQ02 Media
RF02 foto existente.
Driver3- Permitir el registro de solicitudes pre nupcial. En caso de ser nuevo el
REQ04 Medio
RF03 sistema requerirá el ingreso de los datos personales de los cónyuges
Permitir el registro de los datos de los novios. El sistema mostrara los
datos de los cónyuges y a su vez validara que los conyugues estén
REQ05 Alta
Driver4- aptos para ser registrados como novios usando los datos de los
RF04 exámenes de ETS/VIH.
Driver5-
REQ06 Media
RF05 Permitir la emisión del certificado pre nupcial a solicitud.
Considerar búsquedas de doctores por: fechas y horas de
Driver6- disponibilidad, por especialidad. Se deberá presentar información REQ07 Media
RF06 completa del doctor seleccionado, sus horarios, sus especialidades
Considerar búsquedas de exámenes médicos: por especialidad, por
categorías y subcategorías, por horario de atención y especialidad. Se
REQ08 Media
Driver7- deberá presentar información completa del examen seleccionado,
RF07 costos, días de atención, restricciones, tiempos de atención
Driver8- Generar Reportes Estadísticos Detallados y Consolidados. Reporte de
REQ11 Media
RF08 Indicadores.
Driver9- Atender al menos 10 usuarios concurrentes internos (aplicación web
REQ12 Alta
AC01 en la red local).
Contar con bitácoras de trazabilidad y errores, debe permitir
Driver10- identificar: usuario que ejecutó la acción, fecha y hora, acción, REQ13 Media
AC02 mensaje de error y punto de caída en el código.
Driver11- REQ14 Media

RF09 Almacenar la información de los clientes
La plataforma estándar para desarrollo de software de la
Driver11- municipalidad es Java 7 sobre PostgreSQL 5.3 y sistemas operativos REQ15 Medio
REST01 Linux Ubuntu Server 14.04
La aplicación debe estar orientada para personas entre 18 a 65 años de
Driver11- edad, no se consideran funcionalidades de soporte de personas con REQ16 Alto
REST02 discapacidades.
Driver10- La aplicación Web se debe ver de forma correcta y acomodarse
REQ17 Alto
AC03 apropiadamente en móviles de 4’’-5’’ y tabletas de 7’’-10’’
Todas las tablas del sistema deben tener los siguientes campos de
Driver11- auditoría: usuario de creación, fecha de creación, usuario de REQ18 Medio
REST03 modificación y fecha de modificación.
Driver10- El aplicativo web debe responder al usuario en menos de 2 segundos
REQ19 Alto
AC04 en red local.
Driver10- El aplicativo móvil debe responder al usuario en menos de 10
REQ20 Alto
AC05 segundos
2. Elegir un elemento del sistema a descomponer
Módulo examen médico.
Permitir el registro de exámenes médicos de diferentes tipos:

Driver1-RF01 examen médico, exámen odontológico y examen de laboratorio
Considerar búsquedas de exámenes médicos: por especialidad,

por categorías y subcategorías, por horario de atención y
especialidad. Se deberá presentar información completa del
examen seleccionado, costos, días de atención, restricciones,
Driver7-RF07 tiempos de atención
Driver11-RF09 Almacenar la información de los clientes
4. Elegir un concepto de diseño en relación con el elemento y los drivers elegidos.

- COTS: XClinics
- Servicio web: Reniec
- Modelo de dominio:
Elemento Drivers
XClinics Driver1-RF01
Driver7-RF07
Driver11-RF09
Reniec Driver11-RF09
Elemento Responsabilidad
XClinics - Módulo médico permite la subida de archivos, la modificación

de estos, control de examen médicos, la
búsqueda de por especialidad
Consulta DNI Consulta a la base de datos de reniec para la

obtención de los datos del cliente que vaya a
hacerse algún tipo de examen.
6. Definir interfaces para los elementos instanciados.
Elemento Interfaz
Modulo medico Middleware, que permita la comunicación del

sistema de asistencia social con el modulo
medico de XClinics
Consulta DNI Protocolo HTTP, para la captación de datos de

los clientes.
7. Verificar y refinar requerimientos y transformarlos en restricciones de los elementos instanciados.

Con base a los elementos instanciados se llega a validar que los drivers correspondientes al módulo
del examen médico se llegan a cumplir en su totalidad.
Iteración 2
- 2. Elegir un elemento del sistema a descomponer
- 3. Identificar los drivers arquitectónicos asociados al elemento
1 Portal Web Driver10-RF010 Alta

Driver11-REST01
Driver11-REST02
Driver10-AC04
2 Portal Movil Driver10-AC03 Alta

Driver10-AC05
3 Modulo cónyuges Driver4-RF04 Media

Driver2-RF02
4 Modulo pre nupcial Driver3-RF03 Alta
Driver5-RF05
5 Modulo usuarios Driver8-RF08 Media

Driver9-AC01
6 Base de datos Driver11-REST01 Baja
- 4. Elegir un concepto de diseño en relación con el elemento y los drivers elegidos.
Número Elemento Concepto de Diseño
1 Portal Web Patrón Arquitectónico multinivel
2 Portal Movil Patrón Arquitectónico multinivel
3 Modulo cónyuges Patrón Arquitectónico multinivel
4 Modulo pre nupcial Patrón Arquitectónico multinivel
5 Modulo usuarios Patrón Arquitectónico multinivel
6 Base de datos Patron arquitectónico DAO
- 5. Instanciar los elementos y asignar responsabilidades
1 Portal web Recibe peticiones de búsqueda, registro de novios, de

certificación comunicación con otra aplicación.
2 Portal movil Recibe peticiones de búsqueda, registro de novios, de

certificación comunicación con otra aplicación,
pantalla responsiva de acuerdo al móvil o tablet.
3 Modulo cónyuges Registro de novios, validación para el registro.
4 Modulo pre nupcial Registro de solicitudes y emisión de certificación.
5 Modulo usuarios Se encargan de la búsqueda de doctores, registro de

carnet de sanidad.
6 Base de Datos Almacena datos de cónyuges, usuarios, reporte y

doctores.
8 Data Transfer Object Sirve de interfaz entre el modelo y la base de datos.

- 6. Definir interfaces para los elementos instanciados.
1 Portal web Peticiones HTTP y middleware
2 Portal movil Peticiones HTTP
3 Módulo cónyuges Peticiones HTTP y DAO
4 Modulo pre nupcial Peticiones HTTP y DAO
5 Módulo usuarios Peticiones HTTP y DAO
6 Base de Datos DAO: Interfaz común entre la aplicación y la base de

datos
7 Controlador -
8 Data Transfer Object -
- 7. Verificar y refinar requerimientos y transformarlos en restricciones de los elementos

instanciados.
La plataforma tecnológica debe ser

Driver9-AC01 desplegada íntegramente en la nube, REQ12
soportando 100 usuario concurrente internos. Soportabilidad
Arquitectura del sistema de asistencia social.

Práctica 07 - Métodos para Diseñar La Arquitectura

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Práctica 07 - Métodos para Diseñar La Arquitectura

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

FACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

- Alberto Miranda Anderson Leandro 18200247

- Gonzales Julluni, Alexandra Tania 18200081

- Marcos Valdez Alexander 18200089

- Navarro Ortiz Eduardo 18200279

- Rojas Miñan, Alexis Luis Clemente 18200317

- Valentin Ricaldi David Frank 18200103

1. Determinar drivers arquitectónicos

“LimpiaYA” es una empresa relacionada al rubro de venta de productos de limpieza para el

Requisito Funcional Descripción

Tipo de driver Descripción

Debe permitir la configuración de encuestas para distintos propósitos,

La encuesta puede tener una o más preguntas, las preguntas pueden

Las preguntas pueden ser de respuesta de texto abierta o de respuesta

2. Establecer el alcance del proyecto

Análisis y refinamiento de drivers arquitectónicos:

Debe permitir la configuración de encuestas para distintos propósitos,

La encuesta puede tener una o más preguntas, las preguntas pueden

Las preguntas pueden ser de respuesta de texto abierta o de respuesta

Creación del plan de proyecto preliminar:

Etapa Descripción de la etapa Consideraciones

1 Determinar drivers arquitectónicos Número de reuniones con el cliente: 2

2 Establecer el alcance del proyecto Drivers totales obtenidos: 9

3 Creación/Refinación de la arquitectura Tamaño del equipo de arquitectura: 5

Tiempo estimado: 1 semana

4 Evaluación de la arquitectura Tiempo estimado: 1 semana

6 Experimentación Número de experimentos estimado: 3

Duración por experimento: 3 días

Tiempo estimado: 1 semana

7 Plan de producción Tiempo estimado: 1 semana

Integraciones (servicio de terceros):

Patrón arquitectónico elegido para el sistema: 3 capas

ID problema Contenido Driver afectado

Prob1 No se aprecia el envío de correos electrónicos en la Driver4

Prob2 No se llega a entender el apartado de exportar a Excel Driver6

Indicación ¿Se cumplió?

La arquitectura ha madurado hasta el punto en que los diseñadores No

Durante la revisión, el arquitecto pudo explicar cómo respondería el Sí

No se han descubierto riesgos importantes que pudieran poner en riesgo el Sí

Indicaciones sólidas para continuar el refinamiento:

Indicación ¿Se cumplió?

El arquitecto no pudo responder a todas las preguntas de sondeo acerca de No

Hubo respuestas contradictorias a preguntas de sondeo en la arquitectura No

Las partes claves de la arquitectura aún no se han definido No

Se encontraron más de 3 problemas No

Durante la presentación de la arquitectura, el arquitecto tuvo que dibujar No

Elemento Descripción del contenido

Responsable Anderson Alberto Miranda

Objetivo Determinar el impacto en la arquitectura causado por no haber

Resultados esperados Impacto menor en la arquitectura no haber mostrado el envío de

Recursos requeridos No es necesario ningún recurso informático

Artefactos Resultados del plan de experimento EXP1

Descripción del Para realizar este experimento, se revisará la documentación del

Duración Fecha de inicio: 25/08/21

Resultados y Se genera un impacto crítico al no definir correctamente como es el

Formulario de estimación de elementos

Nombre del sistema ELiYA

Nombre del elemento Crear encuestas

Tiempo estimado 3 semanas

Fecha de estimación 27/08/2021

Formulario de estimación de elementos

Nombre del sistema ELiYA