Arquitectura de Software: Adaptación y Escenarios de Uso

Sistema: SISTEMA DE GESTIÓN PARA UNA PELUQUERÍA
Problema que resuelve:

• Gestión de los turnos de una peluquería multisucursal.
• Envío de e-mail recordatorio de turno.
• Gestión de reportes de ventas por servicio.
• Gestión de ingresos y egresos por sucursal y de forma global (vista contador).
• Gestión para registrar un pago total o parcial.
• Automatización de cambios de estado de un turno (DEMORADO, CANCELADO, EN CURSO).
• Multienrolamiento de usuarios.

RNF:

• Ver los turnos en tiempo real.
• Conexión remota a través de una base de datos en un servidor externo.
• Agilidad en la asignación de turnos.
• Rapidez en la notificación de recordatorios de los turnos.

Para hacer el sistema un producto reutilizable …
¿Cómo cambiaría su arquitectura?

• Haciendo una versión web del mismo. Actualmente es una app de escritorio con back en Java (db: MySQL) y front en Swing. Se podría hacer una web app con JS, alojando remotamente una db con AWS.
• Implementando el actual instalador con InstallShield.

¿En qué otro escenario debería repensarse completamente?

• En el caso de una aplicación web, deberían repensarse las tecnologías que se usarían y la curva de aprendizaje correspondiente de cada una.
• Para la app de escritorio, se debería repensar para ser multiplataforma.

¿En qué otros escenarios se mantendría?

• Utilizando otra DB como PostgreSQL.

Proyecto: “Sistema de registro de acceso a autobuses para empleados de una empresa de producción de alimentos”

1.- ¿Qué problemas resuelve?

Aporta un mayor control sobre la informacion acerca del uso de los transportes privados de la empresa, con la finalidad facilitar la toma de decisiones y optimizar recursos.

2.- Requerimientos no funcionales

• El sistema debe validar si un usuario es empleado o no de la empresa.

• El sistema debe registrar la ubicación del usuario donde ingresa a la unidad de transporte mediante GPS.

• El sistema deberá desencriptar el código QR encriptado por seguridad para validar su acceso al a unidad de transporte.

3.- ¿Cómo cambiaría su arquitectura en caso de que sea un producto reutilizable?

 Colocando entidades y atributos en base de datos y funcionalidades del area de backend que sean lo suficientemente genéricos.

4.- ¿En qué otro escenario debería repensarse completamente?

Podría repensarse completamente en casos, donde se requiera controlar la seguridad del entorno en el cual se requiera registrar los accesos. 

5.- ¿En qué otros escenarios se mantendría?

Podría repensarse para el registro de ingreso en edificios o instituciones como escuelas. 

Sistema de Emisión Electrónica (SEE) - desde los Sistemas del Contribuyente
Permite que los Sistemas de Facturación de los Contribuyentes envíen los datos de la factura al componente que realizará la creación de la factura electrónica (XML UBL 2.0) según lo estipulado por Sunat, para luego enviarlo a validar a la entidad validadora (Sunat u OSE).
Asimismo, sincroniza el estado de validación para que sea consumida por el contribuyente en un segundo momento.
Todo esto a través de un proyecto de implementación previo entre el Sistema de Facturación y el componente.
Requerimientos no funcionales

• Generar la factura electrónica (archivo XML UBL 2.0 de acuerdo a lo estipulado por Sunat), hashcode y el arreglo de bytes para la interpretación de la representación impresa (archivo PDF).
• Firmar el XML UBL 2.0 con el certificado digital del contribuyente.
• El certificado digital debe contener los datos de la empresa contribuyente y del representante legal.
• Enviar correo electrónico al receptor de la factura electrónica (archivo XML UBL 2.0 que contiene el hash y la firma del certificado digital).
  Producto re-utilizable
  Este producto se reutilizó para la Boleta, Nota de Crédito y Nota Débito.
  También se reutilizó la arquitectura para los comprobantes de Retención y Percepción (para estos se tuvo que usar una estructura diferente, pero a nivel de arquitectura se mantuvieron las funcionalidades de firma, generación de hashcode y el arreglo de bytes de la representación impresa.
  ¿Cómo cambiaría su arquitectura?
  A nivel de estructura la Boleta no cambió en nada, lo que cambió fueron los valores de la estructura.
  Para el caso de la Nota de Crédito, se reutilizó toda la estructura de la Factura y se agregaron los campos de referencia (para que se conozca a qué Factura corresponde la NC).
  Para el caso de la Nota de Débito, se reutilizó la estructura de la Nota de Crédito en su totalidad, pues tienen la misma estructura pero diferentes valores.
  Para el Caso de las Retenciones y Percepciones, la estructura cambió totalmente, pero se mantuvieron las funcionalidades de generación de hashcode y el arreglo de bytes de la representación impresa.
  Después de construida toda la Suit (F/B/NC/ND/RET/PER) en la versión 2.0 del XML UBL, Sunat cambió la versión del XML UBL, del 2.0 al 2.1, por lo que para hacer la versión 2.1 se reutilizó por completo el estándar UBL 2.0.
  ¿En qué otro escenario debería repensarse completamente?
  En caso deseen realizar la firma de certificado digital de algún otro tipo de documento, debido a que el certificado digital establecido para facturación electrónica solo sirve para F/B/NC/ND/RET/PER (y Guías), si se desea firmar un contrato de trabajo, vacaciones, etc, se deberá cambiar todo por completo.
  ¿En qué otros escenarios se mantendría?
  Para la generación de la Guía Electrónica. Para este caso se mantendría la arquitectura mas no la estructura.

Sistema de Facturación Electrónica, para empresa que presta servicios en distintos países (LATAM)
Problemas que resuelve:
Generar la facturación automática, dado el alto volumen de transacciones realizadas diariamente
Entregar documento fiscal a cliente final, necesario para sus temas contables
Centralizar la consolidación financiera de la empresa
Mantener registro de los impuestos asociados
Requerimientos No Funcionales
Seguridad en la entrega de la información
Generar comunicación con entes fiscales de cada país
Formatos deben ser adecuados según estándar de cada país
Multimoneda - Si paga con moneda foránea, se debe pensar con qué moneda factura, y los tipos de cambio asociados.
¿Cómo cambio su arquitectura? (pensando en la escalabilidad por país)
1.- Disponibilizando micro servicios por funcionalidad: Servicio para tipo de cambio, servicio para cálculo de impuestos y tasas, servicio de formato de factura, servicio de conexión con entes fiscales, etc.
2.- Control de parámetros de aplicación (generales) y por países (fechas, feriados, monedas, etc.)
¿En qué otro escenario debiera repensarse completamente?
En el caso de que el proceso de facturación de la empresa no sea compatible con la aplicación de una facturación automatizada (ejemplo, que en algún país se requiera de una pre-factura)
¿En qué otros escenarios se mantendría?
Si el proceso de facturación se mantiene sin alterar en el nuevo país a implementar, sólo se deben cambiar parámetros dentro de la configuración, por lo que se podría mantener estos servicios con modificaciones incidentales.

Sistema de corresponsal para transacciones bancarias
Problemas que resuelve.

• El sistema otorga a pequeños comercios un sistema de corresponsal bancario para poder ser usado

Requerimientos no funcionales.

• El sistema cuenta con una seguridad en las peticiones incluidas
• El sistema está disponible siempre para su correcto funcionamiento
• El sistema es capaz de almacenar grandes volumenes de transacciones

¿Cómo cambiaría su arquitectura?
No cambiaría mucho ya que el proyecto se planteo desde un principio para abarcar necesidades muy generales
¿En qué otro escenario debería repensarse completamente?
Al integrar otros productos diferentes que no sean transacciones bancarias
¿En qué otros escenarios se mantendría?
Integrar varios tipos de divisas

Un sistema que estoy desarrollando:
**Proyecto:**Sistema de comandas para mi restaurante
**Problema a resolver:**Evitar el uso de papeles anotados a mano para llevar el pedido hasta la cocina.
**Requerimientos no funcionales:**Implementas JWT para la seguridad del sistema. Acceder mediante una página web.
**¿Cómo cambiaría su arquitectura?**Le agregaría un PWA a la página web para acceder desde el celular
**¿En qué otro escenario debería repensarse completamente?**Podría aplicarse la misma funcionalidad en bares, discotecas, etc.

WhatsApp
¿Que resuelve?
Mantiene en contacto a las personas sin importar la distancia, el lugar o la hora. El medio de comunicación más conocido actualmente.
Rerquerimientos no funcionales

• Mensajes sifrados de punta a punta brindando una mayor privacidad.
• Permite hacer llamadas de manera gratuita mediante conexión wi fi o red movil.
• Publicar historias para mantenerse al tanto de lo que hacen tus conocidos.
  Cambios de arquitectura
  Agregar nuevas funcionalidades a la arquitectura de comunicaciones y tranferencia de datos como:
• Implemetar un sistema de tranferencia de dinero y/o pagos ya sea para empresas o ususarios generales.
• Agregar integraciones con servicios de salud para emergencias que no puedan ser atentidas al instante.
  Repensar otro escenario
• En el momento que ocurra una filtración y robo de datos masiva.
• Cuando el protocolo de comunicacines por texto cambie y ya no sea necesaria una conexión a servidores para enviar datos.
  Mantenerse en otro escenario
  Mientras que no exista una competencia de gran impacto y no implementen funcionalidades que hagan molesten a los usuarios. Del feedback depende el exito de las nuevas funcionalidades.

typingclub(https://www.typingclub.com/)
Resulve:
Ayuda al aprendizaje de la mecanografía en un tiempo muy corto, con ejercicios que sueltan la mano para ganar más velocidad a la hora de escribir.
Requerimientos no funcionales

• El acceso rápido por medio de redes sociales.

• Su acceso gratuito.

• Su sistema multi-idioma.

Cambio de arquitectura

Se tendría que modificar su base de datos para añadir los idiomas que no se basan en el alfabeto latino.

Escenario
Para las personas con discapacidades visuales,ya que no esta diseñado para los lectores de pantalla
Otros escenarios
En las instituciones de educación para la enseñanza de la mecanografía.

Sistema para control de calidad de cacao

Que resuelve: Minimiza el error de los indicadores obtenidos en los examenes de cacao, lo cuales son importantes en la negociación entre el comprador y el vendedor de esta materia prima.

Requerimientos no funcionales:

• El sistema de poder calcular los indicadores que espera el comprador de manera confiable y sin errores.
• El sistema debe tener la cualidad de determinar si el valor ingresado esta en los rangos esperados para evitar que se equivoquen en el ingreso de los resultados de exámenes al cacao.
• Informar por sistema al gerente de importaciones para tener bases para negociar el precio de compra.
• El acceso a las opciones del sistema debe ser asignadas al usuario que es responsable del proceso.
• El uso de este sistema de de ambito local. Se analisa el cacao y se lo negocia dentro de la empresa, por lo que no debe ser accedido desde afuera de la empresa.

Como cambiaría su arquitectura:

• Lo cambiaria a un ambiente de desarrollo de última generación.
• Llevaria la base de datos a otra superior, ya que en aquel entonces fue desarrollada con access pero con toda la data que debe tener es importante llevarla a otra plataforma.

¿En qué otro escenario debería repensarse completamente?

• En caso de querer controlar la aplicacion de formulas de control de calidad para otros productos. En este caso solo se penso que seria para cacao, pero si se deseara comercializar este producto, seria necesaria analizar si se adapta, en especial, por los textos utilizados. Se tendria que modificar para que sea mas general.
• Tambien tendria que repensarlo en caso de que necesite interactuar con otros sistemas, en especial, de producción.

¿En qué otros escenarios se mantendría?

• Para los procesos de analisis de cualquier producto que aplique control de calidad.

PROYECTO:
- Implementacion de E-commerce a una Papelera por restricciones del Covid
PROBLEMA QUE RESUELVE:
-la continuidad del negocio por las restricciones que implementa el gobierno por covid-19
-satisfaccion y comodidad del cliente por la saturacion y concentraccion masiva de gente en la matriz y sucursal (tiene horarios que esta lleno de gente para comprar)
- captar clientes que realizan compras por internet.
REQUERIMIENTOS FUNCIONALES:
-disponibilidad
-multiples metodos de pago y confirmacion automatizada del pago
-seguridad en pagos digitales
-confidencialidad de datos
-contratar logistica de terceros
REQUERIMIENTOS NO FUNCIONALES:
-software de facturacion automatizada en la plataforma de compras
-compartir y cordinar inventario de productos tanto en tienda fisica como en tienda digital
-poder hacer pedidos en whatsapp y facebook e implementar en el ecoomerce
¿Cómo cambiaría su arquitectura?
-implementarian funciones y requerimientos de acuerdo a las necesidades del escenario
-cambiaria la implementacion de la logistica interna
-no compartir base de datos ni coordinar prodcutos con la tienda fisica
-podrian hacer entregas fisicas en tiendas
En qué otro escenario debería repensarse completamente?
-en la falla de los servicios de Paqueteria
¿En qué otros escenarios se mantendría?
-en confinamiento muy estricto por covid
- en la implementacion de entregas locales con personal interno

Plataformas de educacion online
Los problemas que resuelve son: la organizacion del contenido para tener una idea general de los temas, facilidad de la creacion de una comunidad y ayuda a los estudiantes para aprender de manera efectiva.
Requerimientos no funcionales: El garantizar el aprendizaje del alumno.
¿Cómo cambiaría su arquitectura? Dejando ejercicios e implementar la IA para revisarlos
¿En qué otro escenario debería repensarse completamente? El dinamismo de la plataforma
¿En qué otros escenarios se mantendría? En el diseño de la plataforma

Sistema de información de Cargue Masivo
Este sistema corresponde a una aplicación de carga masiva de Documentos, que se realiza en tiempo real, mediante una aplicación Web, en la cual se tenia definida una Arquitectura basada en un modelo Vista Controlador, allí, se contaba con un modelo en el cual se implementaron las reglas de negocio de la compañía, que corresponde a las casticistas de validaciones, según el los tipos de Servicio y los tipos de archivos, por otro lado se tenia implementada El modelo de las vistas, que correspondían al desarrollo de la interfaz de Usuario o capa de presentación y el controlador que realizaba la integración y validación entre las reglas de negocio y la capa de presentación.
En esta compañía, se requería realizar una actualización, para mejorar la experiencia de usuario, aunque al mismo tiempo era necesario realizar actualización de la plataforma puesto que las versiones en las cuales estaba implementada la aplicación, ya no eran funcionales para los nuevos servicios y requerimientos del cliente, también era necesario cumplir con tiempos de respuesta para consultas y peticiones menor a un segundo, y un muy alto volumen de transaccional, se debía reutilizar el código de la lógica del negocio, por lo cual la

Arquitectura a implementar en este caso, fue: Un híbrido entre Arquitectura SOA, y Microservicios, La logica de negocio se mantendría, para lo cual lo que se realizo fue: El Front o capa de presentación seria implementado con un Framework JSF con primefaces, versión 6.2 y Primefaces Extensión 6.2.8, un fremawork ligero y muy facil de implementar, puesto que el cambio de arquitectura y actualización debía realizarse en tan solo 6 meses. Para el control de las vistas se apoyaría con un Bean controler. Desde alli se soportarían las validaciones básicas de los Formularios que no hacen parte de la lógica del negocio.
La Lógica del negocio estaría soportada desde la capa de Servicios, realizando la implementación de Servicios y Microservicios REST con la aceptación de JSON. Los microservicios estarían dispuestos para la interacción con datos (Modo consulta) Desde los servicios se realizaría el mayor re-uso de Código de la lógica del negocio. Esto le permite a las organizaciones, implementar y actualizar aplicaciones en el menor tiempo posible si tener que hacer una construcción desde cero.
Y finalmente la Capa de presentación podrá interactuar con la capa de Servicios por medio de una pasarela encargada de la comunicación entre estos.

¿En qué otro escenario debería repensarse completamente?
Considero que la Arquitectura se debe replantear cuando la funcionalidad de los sistemas están llegando a su capacidad máxima de funcionalidad, constitucionalidad, tiempos muy largos de respuesta en las consultas, actualización en las versiones de la plataforma, porque las que se tienen no cuentan con nuevas funcionalidades, mejorar la experiencia al usuario, basada en las estrategias y normas del País, otros factores como: la Capacidad de Uso de los datos o también cuando requiere de integraciones con con otros sistemas y la estructura actual no lo permite, bien sea por compatibilidad o porque el modelo actual es limitado.

¿En qué otros escenarios se mantendría?

Pienso que esta se debe mantener siempre y cuando cumpla con los requerimientos funcionales del sistema o las características básica de el.

Que sea estable, escalable, sostenible en el tiempo (Mantenimiento-soporte), usabilidad, accesibilidad a la data, y que se pueda integrar si se requiere.

Descripción:
El sistema permite la gestión de los períodos de vacaciones de los empleados de una compañía desde su solicitud hasta la aprobación y disfrute de las mismas.

Requerimientos
Asegurar el ingreso de los usuarios al sistema.

¿Cómo cambiaría su arquitectura?

Actualmente el sistema se ha implantado usando el patrón Modelo - Vista - Controlador, en una arquitectura monolitica. Esto lo cambiaría para generar una API que provea los servicios, de tal manera que se puedan utilizar desde diferentes clientes a través del consumo de servicios REST.

¿En qué otro escenario debería repensarse completamente?

Podría pensarse como un manager de procesos capaz no sólo de abordar la ejecución del proceso de solicitud y aprobación de vacaciones, sino cualquier otro proceso interno de la empresa que pueda ser definido.

Sistema de Gestión de Riesgos
Problemas que resuelve:

• Gestiona los riesgos de los procesos de la institución
• Cálculo automático del nivel de riesgo
• Registro, programación y asignación de acciones de control de riesgos
• Recordatorios de acciones de control
• Facilita la revisión de entregables de acciones de control
• Generación de informes de gestión de riesgos
• Cálculo de riesgo residual

RNF:

• Despliegue ON PREMISE
• Lenguaje angular 11, java 8
• App Server payara server 5
• BD ORacle 19C
• Diseño basado en angular y material design
• Resolución Mínima: 1300x768px
• Comunicación HTTPS
• Gacer uso del Sistema de COntrol de Accesos a Sistemas Informáticos (SCASI)
• Tiempo de sesión: 1 hora de inactividad
• Uso desde Chrome 84.0 o superior
• Tiempo de descarga máximo: 5 segundos
• Disponibilidad 90% o más

Para hacerlo un producto reutilizable:

• Personalización de logos y colores de pantallas
• Personalización de formatos y reportes
• Independencia del SCASI

¿En qué otro escenario debería repensarse completamente?

• Cambio en la metodología de gestión de riesgos
• Despliegue en nube

¿En qué otros escenarios se mantendría?
Cambios en motor de base de datos

Sistema
Tienda en linea de una marca deportiva famosa para sus atletas con patrocinio
Problema que resuelve

• Poder acceder a un catalogo diferente (precios y productos) al de la tienda convencional abierta a todo publico
• Nuestros atletas puede comprar con el patrocinio anual cualquier producto disponible en la region donde se hara el envion
• Nuestros atletas pueden invitar contactos (familiares, amigos) para usar una parte de su patriciono y poder comprar

Arquitectura

-Microservicios, puesto que muchos de nuestros componentes (carrito, gestion de compras, envios) son mantenidos por otros equipos, siguiendo la ley de Conway

Escensarios a repensar

• La segmentacion de componentes de backend hacia containers y orquestamiento (hablando de integracion con Docker y k8s) podria facilitar el proceso de CI/CD sin sacrificar la disponibilidad de la tienda en linea.

Uber

Problemas a resolver:
1-El no tener un auto para trasladarse
2-El no tener una agencia de taxis cerca de donde vos estas
3-El monopolio por parte de los taxis cerca de aeropuertos y su aprovechamiento hacia los turistas

Requerimientos No Funcionales:
1-Calidad del auto donde el usuario se traslade
2-Conocimiento de datos del conductor, como así también del pasajero
3-Poder pagar con efectivo, dado a que no en todos los países se acostumbra el pagar con tarjeta de crédito
4-Ofrecer precios de manera proporcional a la demanda y oferta de viajes

¿Cómo cambiaría su arquitectura?
Su estructura está bastante bien diseñada para aquellos servicios que dispongan de usuarios como trabajadores y otros como gozadores. Quizá, debería cambiar su interfaz fuertemente dirigida hacia la movilización, apoyada en el mapa gps que aparece como principal objeto en pantalla.

¿En qué otro escenario debería repensarse completamente?
Su estructura debería de ser repensada cuando se tratase de una empresa cuyo objetivo es vender un servicio o producto con un precio fijado por la misma empresa, que también sea esta quien elija específicamente que persona física ofrezca su producto o servicio, y que ademas ofrece un productos o servicios en una amplia variedad, como listas de productos etc…

¿En qué otros escenarios se mantendría?
Quizá en apps de delivery de comida podría mantenerse, ya que podría geolocalizarse nuestro pedido de comida al igual que se hace con el automóvil pedido, y el mismo mapa podría servirnos como seleccionador del lugar a donde queramos ordenar comida, para ver así que opciones tendríamos disponibles. Las personas que llevan la comida, serían los mismos que en la realidad conducen los Uber.

sistema conocido
Sistema de acceso a personas a empresa

Describir qué problemas resuelve

• Verifica que cada empleado tenga la documentación referente a su empresa al día (seguros, cursos, examen médico) y da acceso a planta por medio de reconocimiento dactilar.

cuáles son sus requerimientos no funcionales.

• Tener varios usuarios con escala de privilegios, poder importar y exportar marcaciones a base de datos, ver en tiempo real las personas adentro de planta, rechazar personas con documentación vencida, envío por mail a las empresas el aviso de documentos próximos a vencer.

Si tuvieras que hacer de éste software reutilizable
Tengo algunas ideas para una startup

¿Cómo cambiaría su arquitectura?
Pondría una base local a cuál se tenga acceso vía HTML para que las empresas carguen la documentación ellas mismas, usando reconocimiento inteligente.
El otro acceso a la base sería para que funcione el programa y pondría un sistema aparte que se actualice constantemente con las personas que entran y salen, y que envíe un reporte automático personalizado.

¿En qué otro escenario debería repensarse completamente?
En los caso que las personas que ingresan a la planta no sean contratistas fijos, sino sean visitas eventuales

¿En qué otros escenarios se mantendría?

En casos en los que hay personal fijo, o lugares en donde haya vehículos en vez de personas

Sistema de control de salud y personal:

• Problema a resolver: tener control de ingresos y egresos del personal y seguimiento de sus consultas medicas.
• Requerimientos no funcionales:
  • Mostrar información en tiempo real.
  • Diseño intuitivo.

• Se debería de repensar totalmente si cambiaran el método de ingreso actual de personas y se mantendría si se sigue usando el mismo método.

Sistema de cita para veterinarios:

Que problema resuelve:

Esta aplicación es un gestor de cita para la vacunación de mascota , dando la oportunidad al usuario de la pagina , de poder agendar su cita para su mascota y llevar un control de su vacunas.

Requerimientos no funcionales:

Almacenar la información del cliente.

Almacenar la información de la mascota.

Guardar el día y hora agendado.

Llevar un control de las vacunas ya puestas.

Que cambiaría

Desarrollaría esta aplicación para uso móvil.

Usaría un código QR, que se imprima en la medalla de la correa de la mascota, para obtener una forma de manejar la información mas fácilmente par cualquier veterinario.

Sistema de ventas por redes sociales

• Problema que resuelve:
  Encontrar el mejor producto o servicio lo más rápido posible y en un solo lugar.
  Requerimientos no funcionales:

1. seguridad en los pagos y cobros.
2. seguridad en el manejo de la información.
3. veracidad y calidad de los servicios y productos ofrecidos
4. rapidez en contestar a preguntas de usuarios

Producto Reutilizable:

¿Cómo cambiaría su arquitectura?
La arquitectura sería cambiada al 100%, en la actualidad esas redes de ventas dependen casi que
exclusivamente de ventas por redes sociales las cuales no son seguras, ni confiables ni tampoco escalables.
Empezaría por hacer una estructura formal de ventas mediante una app donde pueda registrar clientes y vendedores.

¿En qué otro escenario debería repensarse completamente?
Creo que el sistema debería repensarse completamente en el escenario regional, el sistema esta hecho para cumplir con los pedidos y compras de la ciudad, ya que depende de la movilidad del vendedor y de su tiempo por lo cual no podría ser competente a nivel regional.
¿En qué otros escenarios se mantendría?
El escenario donde se mantendría sería en las paginas web, ps la mayoría de ventas son realizadas y/o contactadas por dispositivos móviles usando aplicaciones de chat o por referencias de otros usuarios quienes hacen llamadas telefónicas a los vendedores.

Sistema OTRS para Mesa de Ayuda en áreas de TI
¿Que Problemas Resuelve?
Es una solución usada para el manejo de la gestión de soporte técnico TI en empresas, manejo de Niveles de servicio o respuesta a incidencias, registro de incidencias, control y seguimiento de las mismas.
Reuqerimientos no funcionales:
• El sistema permite manejar entidades independientes, util para manejar por ejemplo varias empresas independientes gestionando incidencias e inventarios de equipos de forma independiente.
• el sistema permite manejar diferentes roles de usuario de acuerdo al perfil que se requiera.
• el sistema lleva control de fechas de vencimiento de servicios y/o licencias y notificaciones al respecto,
• el sistema permite realizar Backup de la base de datos de manera facil y rapida
¿Como cambiaria su arquitectura?
Se pueden hacer mejoras en el código deacuerdo a necesidades específicas de cada empresa, el sistema de por si es libre y de código abierto y la comunidad aporta a realizar las mejoras y actualizaciones, es una plataforma a mi parecer facil de modificar en su codigo fuente pues esta hecha en HTMl CSS y PHP.
¿En que otro escenario debería repensarse completamente?
Pensaría que para adaptarlo a dispositivos móviles pero esto sería algo parcial, un caso para repensarlo totalmente sería si se crearan nuevas tecnólogias de codigo, algo similar a como pasó con el cambio de HTML a HTML5 o la obsolecencia de Flash que paso a ser reemplazado por HTML 5 y CSS3.
¿En que otros escenarios se mantendría?
Considero que esta aplicación se puede mantener por bastante tiempo debido a que maneja un entorno WEB

Sistema: INE
Problema que resuelve: Muestra estadísticas públicas relacionadas al país.
Requerimientos no funcionales: Actualizado, disponible, mantenible, eficiente y consistente.
¿Cómo cambiaría su arquitectura?: Estructuraría la data de una mejor manera y la distribuiría por diferentes bases de datos según el propósito de uso de la data. (Ya sea búsqueda, filtro, relación, grandes cantidades), por lo que, sería un cambio en la infraestructura para agilizar su distribución, ergo, su consumo.
¿En qué otro escenario debería repensarse completamente?: En todo entorno. Estructurar bien la información y saber con que herramienta distribuirla según será su uso es vital para todo ente social.
¿En qué otros escenarios se mantendría?: Según el diseño en mente, se podría mantener en diferentes escenarios.

Sistema:

• xHub Profile - Generador de perfil personalizado en GitHub a partir de la información de LinkedIn

Que problema resuelve?

• Crear un perfil personalizado de GitHub a partir de la información de una cuenta de LinkedIn
• Actualizar periódicamente el perfil de GitHub si la información de LinkedIn cambio
• Permitir la sincronización parcial usando diferentes tipos de templates donde el usuario puede poner lo que considera importante como información de contacto u otros
• Seleccionar la información de LinkedIn que se desea sincronizar
• Pagos por sincronizaciones ( Integración )

RNF:

• Soportar muchas solicitudes de actualización
• Manejar datos de la integración con extrema precaución
• Cumplir los requisitos de protección de datos de la UE (GDPR)
• Ajuste de numero de servidores según la demanda (Auto Scale)

Si tuvieras que hacer de este sistema un “producto reutilizable” en otros escenarios:

¿Cómo cambiaría su arquitectura?

• Usar un modelo genérico de ejecución de tareas, donde las tareas pueden ser aumentadas como plugins
• Ademas de usar algún protocolo estándar y un MQ como RabbitMQ para la distribución de tareas entre los workers

¿En qué otro escenario debería repensarse completamente?

• cuando las tareas son operaciones demasiado cortas no es necesario la cola de trabajo

¿En qué otros escenarios se mantendría?

• cuando se tiene operaciones asincronas y se quiere distribuir esa carga entre muchos workers

Chatbot asesoría financiera.

1. Descripción del problema.
   Los asesores de servicio al cliente de una empresa Fintech desean tener un chatbot que responder las preguntas frecuentes que realiza un cliente cuando llama a pedir asesoría, se requiere descongestionar la línea telefónica y usarla sólo en casos de generar nuevos clientes o para requerimientos particulares.

2. Requerimientos no funcionales.
   El chatbot debe tener un horario de atención de 8 a.m a 10 p.m
   El chatbot debe tener respuestas que no demoren más de 3 segundos.
   Se requiere seguridad por medio de un token de seguridad para cada sesión de chat iniciada.
   Debe funcionar para el proveedor de mensajería Whatsapp.
   En caso de falla el chatbot debe indicar que debe contactarse con un asesor a la línea telefónica.

3. Productor reutilizable en otras arquitecturas. ¿Cómo cambiaría su arquitectura?
   En caso de ser un chatbot que también tuviera su propia web, es decir un host a donde se dirige cuando un cliente inicia una conversación, que no fuera sólo por una app de mensajería como whatssap, allí habría que publicar el chatbot en la nube para que fuera usado desde la web.

4.¿En qué otro escenario debería repensarse completamente?
Habría que replantear totalmente el proyecto si también incluyera un chat online con el asesor directamente, en caso de no tener una respuesta satisfactoria por parte del chatbot el cliente sería redireccionado a entablar una conversación con un asesor, allí habría que validar la creación de sockets o webhooks para la integración.

1. ¿En qué otros escenarios se mantendría?
   Habría que evaluar las integraciones con otras plataformas como Telegram, Whatsapp plus, entre otras para que puedan los clientes comunicarse desde su herramienta favorita de chat, bastaría con integrar los servicios de cada proveedor de mensajería.

SISTEMA DE CAJEROS AUTOMÁTICOS DE UNA CAJA FINANCIERA – AGENCIA PEQUEÑA

Describir qué problemas resuelve y cuáles son sus requerimientos no funcionales:
• Permite el cobro de dinero y otras transacciones mediante cajeros ATM.
• Cambio de contraseña.
• Genera reportes sobre Movimientos de Cuenta.
Como requisito no funcional está la disponibilidad de la aplicación del cajero las 24 horas por 7 días de la semana.

Si tuvieras que hacer de este sistema un “producto reutilizable” en otros escenarios:
¿Cómo cambiaría su arquitectura?
Para que crezca como negocio debe dar soporte a otros perfiles de usuario. Como por ejemplo que permita hacer transacciones por la web y móvil. Que tanto CAJEROS ATM, WEB y MÓVIL tengan actualizaciones en línea de las operaciones que hagan los clientes. Que las transacciones que se puedan hacer en el CAJERO ATM se actualicen en la nube, que exista una arquitectura mixta tanto física como en la nube para que se valide el acceso de usuarios por ejemplo con la utilización de un servicio que pueda estar en un espacio privado en la nube para esta financiera.

¿En qué otro escenario debería repensarse completamente?
Debe repensarse su actual arquitectura para el soporte de funcionalidad por Web y aplicaciones móviles. Sobre todo para Cajeros ATM sucursales, pues se hace también necesario tener una arquitectura que soporte un sistema distribuido.

¿En qué otros escenarios se mantendrían?
Se mantendría para ciertos tipos de clientes, por ejemplo aquellas personas que tengan dificultad para manejar tecnología móvil o web. También puede ayudar en zonas rurales donde no hay acceso a internet o las personas no pueden acceder a celulares de gama media para correr aplicaciones móviles.

Sistema: PLATAFORMA WEB PARA LA GESTION DE AFILIACIONES DE TRABAJADORES A CAJA DE COMPENSACIÓN

1. Problema que resuelve: Afiliación, reafiliación, reingreso y retiro de trabajadores a empresas.
   RNF:

• El sistema debe permitir la afiliación, reafiliación, reingreso y retiro del trabajador en tiempo real.
  -El sistema debe permitir conexiones simultáneas
  -El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario final.
  -El sistema debe ser capaz de procesar 10000 solicitudes por segundo.

1. ¿Cómo cambiaría su arquitectura en caso de que sea un producto reutilizable?
   La plataforma es parametrizable de manera que otra compañía la podría adaptar según su necesidad.
2. ¿En qué otro escenario debería repensarse completamente?
   Si se quiere evolucionar a una aplicación móvil.
3. ¿En qué otro escenario se mantendría?
   Migrar de on-premise a la nube

El software de manejo de tramites se ejecuta en la página web.
Problemas que resuelve:
-Envió de de diferentes tipos de tramites.
-Permite la derivación de en base a su motor de derivación con sus reglas de negocios.
-Genera documentos intermedios entre cada derivación.

Requerimientos no funcionales:

Estar disponible todo el tiempo.
Envió de mensajes al dueño del tramite.
¿Cómo cambiaría su arquitectura en caso de que sea un producto reutilizable?
Implementar una arquitectura de microservicios mas robusta, no solo tener Apis de conexión

¿En qué otro escenario debería repensarse completamente?

Agrupar en todos los servicios en una única arquitectura.
En caso de tener tramites sin reglas de negocio pre establecida.

¿En qué otros escenarios se mantendría?

Para cualquier otra página web donde los tramites son sencillos en cuanto a su flujo y reglas de negocio. Únicamente se tendría que crear el tipo de tramite.

Dispositivo de Monitorización de Transformadores

• Resuelve:
  • No es fácil predecir la vida útil de un transformador y sus fallos
• Requerimientos no funcionales
  • Registro de métricas en transformadores
  • Descarga inalámbrica de los datos registrados
• Para hacerla reutilizable, separaría en la arquitectura los medios de adquisición (orígenes de datos) de la implementación
• Debería repensarse completamente si se piensa usar con agua o gas
• Se mantendría en todo escenario que involucre mediciones eléctricas

sistema
Automatización de procesos documentales
problemas

• Mala manipulación de la información
• Retraso de trabajo
• Perdida de información
  Requerimientos
• servicios específicos
• reducción de código con ayuda de un framework

El software sobre el que se realizara el ejercicio es un chat bot que se ejecuta en la página web de una empresa hotelera.
Problemas que resuelve:
-Funciona como sistema de atención resolviendo dudas comunes.
-Facilita la navegación por la página especificando donde puede encontrar lo que se está buscando.
-Optimiza la atención al cliente, quitando un volumen grande de problemas generales, dejando los problemas específicos de los clientes a la persona encargada.

Requerimientos no funcionales:

• Comunicarse de forma clara con el cliente.
• Estar disponible todo el tiempo.
• Comunicarse con múltiples usuarios simultáneamente.

¿Cómo cambiaría su arquitectura en caso de que sea un producto reutilizable?
La arquitectura actual es una orientada a micro servicios. En la cual el chat bot como tal es un micro servicio. Para volver el chat bot un micro servicio para una app nativa o móvil (los cuales son los únicos dos casos que se me vienen a la mente). Solo habría que modificar la manera en la que se conecta al entorno.

¿En qué otro escenario debería repensarse completamente?

Si se quiere que el chat bot mejore sus respuestas con bases a la interacción con los clientes. Este debería constarse a una bases de datos para almacenar las conversaciones y con base en estas modificar su comportamiento. Además de conectarse con más partes del sistema para obtener información del usuario.

¿En qué otros escenarios se mantendría?

Para cualquier otra página web la arquitectura se mantendría. Únicamente se tendría que modificar unos cuantos archivos.

_Posdata: No tengo muy claro este tema. Si alguien encuentra un erro en mis respuestas por favor hágamelo saber. _

**Aplicación para previos aduanales. **
Problema que resuelve: permite a los tramitadores realizar un previo de mercancía, cumpliendo con todos los factores necesarios para su liberación (fotos, información, detalles, documentos).
Requerimientos no funcionales:
La aplicación deberá permitir ingresar con diferentes tipos de empleados, debe haber seguridad de datos, y una base de datos para futuras consultas.
¿Cómo cambiaría su arquitectura?
De acuerdo al diferente tipo de roles dentro de la aduana, cambiaría su arquitectura cada vez que implementemos un nuevo rol (Tramitador, Ejecutivo, Recolector, Agencia Aduanal, Líneas aéreas, Consolidadoras)
¿En qué otro escenario debería repensarse completamente?
Cuando el uso de la aplicación tenga uso nacional (diferentes aduanas y puertos).
¿En qué otros escenarios se mantendrían?
Se mantendría siempre y cuando se aplicaran los mismos roles de inicio.

Servidor Web Socket para domotica

• Problemas que resuelve:

1. Envío y recepción de cadenas de instrucción encriptadas.
2. Actualización de estado en una base de datos, usando las cadenas para saber el identificador del dispositivo a actualizar

• Requerimientos no funcionales:

1. Comunicación de acciones tomadas en la interfaz de usuario (prender apagar una lampara, motores, etc) hacia tarjeta electrónica central
2. Ejecución de instrucciones en cadena (escenarios) a determinada hora sin intervención del usuario.
3. Ejecución de instrucciones en cadena (escenarios) si se detecta la activación de uno o más sensores de movimiento pero solo cuando la luz natural después del anochecer y antes del amanecer

• ¿Cómo cambiaría su arquitectura?
  Se removerían los requerimientos no funcionales que el usuario no dispusiera.
• ¿En qué otro escenario debería repensarse completamente?
  En el caso de que la tarjeta electrónica central elegida no pueda realizar una conexión hacia un servidor WebSocket

Plataforma de integración de sistemas de seguridad en sistemas penitenciarios federales

La plataforma resuelve la operación de los diversos sistemas de seguridad de un centro penitenciario federal, integrados en una plataforma central y de fácil operación por elementos de la policía penitenciaria de forma centralizada y de alta disponibilidad y de robustez necesaria para poder presentar en tiempo real alarmas y eventos relacionados a la operación de un centro federal de readaptación social,

requerimientos no funcionales, el poder permitir la integración de 13 diferentes sistemas y poder concentrar toda la actividad entro de un centro federal en una sola plataforma.

¿Cómo cambiaría su arquitectura?
El general modulación dentro de la interface de usuario para poder manipular de forma mas simple la presentación de todas las alertas y eventos de monitoreo

¿En qué otro escenario debería repensarse completamente?
Posiblemente en escenarios como edificios inteligentes donde ya se encuentran sistemas de control similares

¿En qué otros escenarios se mantendría?
Escenarios donde el control de eventos, el control de acceso y el seguimiento por medio de cámaras de vigilancia pudieran interactuar de forma natural, por ejemplo un banco.

En la empresa utilizamos un sistema que nos permite contabilizar todo nuestro inventario de manera digital y más ordenado, también nos ayuda a saber el costo producción de nuestros productos compuestos.
el sistema tiene una parte de vente, que es donde se comanda todo lo que el cliente esta pidiendo o llevando, tal vez la estructura o la visualización podría cambiar dependiendo el giro de la otra empresa.
otro escenario que debería repensarse completamente es los bienes y raíces, marketing digital, imprenta, financiera etc.
otros escenarios donde se mantendría es todo aquel que tenga productos, insumos en almacén y quiera administrarse su contabilidad, la facturación, la ventana de venta al publico, etc, podría ser desde un abarrotes, un super mercado, tienda de pinturas, venta de autopartes, restaurantes, tiendas de ropa o calzado.

Sistema
CRM

Problema que resuelve

• Permite administrar la información de los prospectos y clientes para que cualquier colaborador que tenga interacción con ellos pueda tener una visión 360.
• Asiste al proceso de conversión de prospecto a cliente.

Requerimientos no funcionales

• Disponibilidad 24/7, multiplataforma
• Seguridad nivel banco
• Integración con plataformas de automatización de marketing y financieras

¿Cómo cambiaría su arquitectura?

• El sistema funciona, pero no hubo arquitectura, se contrató como SAAS y se fue construyendo “de a poquito”. Crearía la arquitectura a partir de los procesos de negocio.

¿En qué otro escenario debería repensarse completamente?

• Si se tratara de una empresa que fabrica bienes en lugar de servicios. Inclusive en empresas de servicios con otros giros

¿En qué otros escenarios se mantendría?

• En empresas del mismo giro.

Saludos
Tengo una app para android que resuelve problemas de Física, los requerimientos no funcionales, son la conexión de estudiantes y profesor en tiempo real , así como también el proceso de login únicamente con cuentas institucionales.

¿Cómo cambiaría su arquitectura?
La arquitectura de desarrollo no se inmutaría si la app se despliega al sistema IOS
¿En qué otro escenario debería repensarse completamente?
En entornos web
¿En qué otros escenarios se mantendría?
Para android

Aplicación de gestión de housekeeping hotelera.
Se trata de una aplicación integrada en un PMS de gestión hotelera completo. Por tanto integrada con otras aplicaciones/ módulos de la aplicación de backoffice que permite desde la gestión de reservas, de la estancia de los clientes y los distintos servicios proporcionados y cobro.

La peculiaridad de esta aplicación es que sería conveniente que el personal no tenga que desplazarse a un terminal para poder obtener información de la aplicación sobre las necesidades de limpieza hotel según ocupación y otras tareas planificadas. Por tanto el cambio en la arquitectura pasaría por adaptar para uso con tabletas que permitan la movilidad y la actualización y consulta online des sistema. Requeriría del uso del wifi protegido corporativo en cada hotel para uso seguro. Acceso y autentificarían por tanto de los usuarios y dispositivos habilitados al uso.

Permanecerían las mismas funcionalidades de backoffice disponibles hasta ahora que además se verán alimentadas en parte por las gestiones que se realicen desde las tabletas ya que la información se encontraría centralizada.

Herramienta de Creacion y Gestion de Facturas.

¿Que problemas resuelve

• Permite crear, almacenar y llevar un control de facturas emitidas formato fisico y digital.

Requerimientos no funcionales

1. Almacenamiento de  información de los clientes
2. Almacenamiento de informacion de precios y productos.

¿Que cambiaria?

1. La aplicación funciona de forma local y para un solo usuario.
2. La aplicación no esta conectada con los demas modulos y/o departamentos de la empresa (Eje.: Contabilidad, Ventas, Cartera y Cobro)
3. Sus datos pueden ser modificados facilmente de forma manual.

Un sistema de cursos, docentes, estudiantes y calificaciones de un colegio

Resuelve la necesidad de gestionar en un solo lugar de manera digital todas las asignaciones de cursos, docentes y estudiantes, y manejar el sistema de calificaciones, a partir de una plataforma web.

No funcionales serían… disponibilidad, seguridad, interfaz amigable

Se me ocurre que otros escenarios sería reutilizarlo para universidades

Cambiaría quizás en cuanto a la agrupación que no es por grados, sino por semestre académico

Se repensaría por completo si se va a integrar con otros sistemas y se le van a añadir funcionalidades como algún elemento de interacción social como foros o algo así

Se mantendría para cualquier otro colegio

Tenemos un problema: El control de documentos que se genera dentro de un proyecto determinado.

La solución: Realicé un sistema en Access (Sí, lo sé). Que permitía controlar la documentación y no sólo eso sino que podíamos generar consultas interesantes con la información almacenada (promedios, contabilidad, montos, etc.).

Riesgos:

• Los riesgos que se tienen con dicha aplicación es que se trabaja de manera local, haciendo que si se pierde la información, perdemos toda la data. Trabajamos dentro de OneDrive, con lo que solucionamos ya que contamos con un respaldo.
• Si quisiéramos trabajar de manera simultánea, no se puede, puesto que sólo permite trabajar con un usuario, a fin de evitar que se corrompa la data.
• No todos podemos usarla, haciendo que el ingreso de la información sea más lenta de la que se genera, haciendo que exista una demora.

Sistema: ase1
¿Que problemas resuelve?
Le brinda la calificación de cada uno de los parciales y la del semestre a los alumnos de la institución educativa a la que pertenezco; a parte nos brinda otras opciones como el poder consultar el calendario oficial, el horario de clases, saber quien es el impartirá la materia, poder conocer y escribirse a los intersemestrales, extras, talleres de cultura; tambien se pueden hacer tramites de varios tipos y también permite hacer quejas anónimas.
Requerimientos no funcionales:
La seguridad que la información del alumno se encuentra protegida, que durante tiempos de mucho trafico en la red va a trabajar lo mejor posible y que exista un correcto manejo de la información personal por parte de la institución.
Si tuvieras que hacer de este sistema un “producto reutilizable” en otros escenarios:
¿Cómo cambiaría su arquitectura? La volvería a replantear para que genere una mejor experiencia al usuario, y poder proporcionarles una mejor retroalimentacion a cada uno de los alumnos en cada materia, y que los usuarios tengan la posibilidad de hacer feedback al equipo que mantiene la plataforma.
¿En qué otro escenario debería repensarse completamente?
En los que no tienen que ver con una institucion educativa, por ejemplo para empresa se tendría que adecuar para que los empleados en vez de “calificaciones” tengan indicadores de que tan efectivo a sido el trabajo que han echo o la calidad de este, por poner unos ejemplos.
¿En qué otros escenarios se mantendría?
En otras instituciones educativas que necesiten brindar el servicio de entregar calificaciones via online

Sistema: Chiper Empresario
Problemas que resuelve: 1 solo proveedor de productos de canasta familiar a tiendas de barrio.
Requerimientos no funcionales:
-Control de inventarios y abastecimiento en bodegas.
-Ventas de productos a todas las ciudades de Colombia.
-Tecnología a los clientes para que utilicen nuestra tecnología.
¿Como cambiaría su arquitectura?
Diseñando un centro de ayuda para que los clientes solucionen de forma automatizada todas sus preguntas y problemas que llegasen a tener con el sistema.
¿En qué otros escenarios se mantendrían?
Ventas de productos de todas las tiendas de barrio.
¿En qué escenarios se mantendrían?
Organizaciones que se dediquen a vender productos de canasta familiar online.

Sistema:
SIA (Sistema de información académico) de la universidad desde el rol del estudiante

**El problema que resuelve es: **
-Provee al estudiante toda la información sobre su situación académica, por semestre suministra las notas de acuerdo con las materias que este cursando, va calculando el PAPA (promedio académico ponderado acumulado), gestiona los procesos de certificados, pagos de matriculas o deudas ante la universidad y es el medio para realizar el proceso de matriculas e inscripción de asignaturas, por semestre.
**Los requerimientos no funcionales podrían ser: **
-Seguridad ya que el estudiante debe contar con una cuenta donde se encarga de gestionar sus procesos de matricula y otros usuarios no pueden intervenir en ella, por otra parte, el estudiante debe poder visualizar las notas, pero no modificarlas.
-Usabilidad debe tener una interfaz gráfica sencilla y que sea comprensible ante todo tipo de usuarios.
-Eficiencia el sistema debe ser rápido trabajar en el orden de los micro hasta milisegundos, con el fin que en el momento de realizar una matricula no se quede sin cupo en una asignatura, al igual que al realizar algún pago.
-Disponibilidad, confiabilidad y mantenibilidad el sistema debe estar disponible para prestar el servicio adecuadamente, no debería de caerse el sistema ante actualizaciones.

Como producto reutilizable lo implementaría en:
Al ser un sistema de información académica podría implementarse también en colegios, o la base del sistema de información se utilizaría en sectores públicos.

¿Cómo cambiaría su arquitectura?
-Automatizaría todo el sistema, ya que este es dependiente de procesos manuales, al realizar algunas solicitudes es necesario que se reúna el consejo, dejen actas y aprueben dichas solicitudes, esto se podría realizar todo de manera virtual, generando mejores resultados.
-Mayor libertad a los docentes para subir sus notas sin ceñirse a una estructura, ya que los métodos de evaluación son diferentes.
-Mejor visualización del sistema, ya que posee una interfaz mediocre.
-Mayor interactividad con el usuario, el sistema es poco intuitivo, por lo que, al realizar búsquedas de asignaturas, uno debe realizar un procedimiento extenso y que a veces no tienen la información que se necesita.
-Actualización de la información

En cuales escenarios:
-Se considera que podría ser implementable en cualquier escenario público.

Online Judge

Problemas que resuelve : Automatiza la manera en que los programadores practican haciéndolo más ágil.
Posibilita a las empresas a encontrar talento para sus proyectos de desarrollo de software.

Requerimientos no Funcionales : Fiabilidad, ya que se requiere que el sistema revise correctamente el código que se envía para solucionar los problemas.
Usabilidad, ya que debe ser fácil de usar sin tener muchos conocimientos de programación para las personas que empiezan en el mundo de la programación.

¿Cómo cambiaría su arquitectura? : Modificando los roles para que personas y empresas puedan personalizar y hacer sus propios concursos de programación privadamente.
¿En qué otro escenario debería repensarse completamente? : En otros campos de la enseñanza diferentes a la programación.
¿En qué otros escenarios se mantendría? : No lo sé 😕

Glovo
Resuelve:

• Entregas a domicilios de comida, supermercado.
• Envíos de cosas.
• Solicitudes para buscar cosas.
  Requerimientos no funcionales:
  -Notificación del proceso del pedido.
• Seguridad de protección de ubicación de cada usuario.
• trazabilidad visual del pedido.
  ¿Cómo cambiaría su arquitectura?
  -Reutilizaría este producto para entregas de mayor carga de empresas, modelándolo a un negocio (B2B) donde los camioneros o muleros puedan participar como stakeholders, ampliando así funcionalidades en el sistema, como tipos de vehículos, tamaños y ruedas e implementando a través de GPS externo un timeline en tiempo real del punto de partida hasta el punto de entrega.
  ¿En qué otro escenario debería repensarse completamente?
  -Un sistema para saber que productos vende que almacen, restaurante, etc. Con el fin de conocer el precio proporciones y cantidades
  ¿En qué otros escenarios se mantendrían?
  -Ninguno

Todavía no tnego una aplicación tan compleja en producción 😦 y mi experiencia con tecnologías no es tan amplia 😦

Sistema de Identificación de intervalos disparados en campos petroleros
¿Qué resuelve?
Permite la identificación de zonas explotadas y el cálculo de su aporte a lo largo de las décadas.
Requerimientos no funcionales:

• Acceso desde cualquier equipo con Microsoft Excel.

• Información obtenida de documentación impresa.

• Información almacenada en hojas de cálculo.
  ¿Cómo cambiaría la arquitectura?

• Desarrollaría un software externo a la paquetería de Microsoft.

• Desarrollaría objetos en el código y no un código único repleto de for’s y while’s

• Crearía una verdadera base de datos.
  ¿En qué otro escenario debería repensarse completamente?
  Cuándo se quiera expandir o rentar.
  ¿En qué otros escenarios se mantendría?
  Escenarios dónde no exista una competencia directa.

Resuelve:
Manejo de recursos e inventarios físicos para la instalación de servicios de hogar y móviles

Requerimientos no funcionales:
*Acceso seguro al sistema de acuerdo al rol que tiene el usuario definido en la aplicación
*Carga de inventarios de manera masiva y manual en el sistema
*Consulta de la agenda del técnico de acuerdo a la capacidad y las franjas horarias establecidas por servicio suministrados por un web service externo.

¿Como cambiaría su arquitectura?

Actualmente este proyecto gestión las inventarios y los recursos físicos para la prestación de servicios de hogar y móviles.
Cambiaría su arquitectura integrándolo a otra aplicación que me mostrara la vista 360 del cliente al cual se le prestan finalmente esos servicios y así tener una visión mas integral del flujo del negocio.

¿En que otro escenario deberia repensarse completamente?
En las exposicion y el consumo de servicios web Rest para ser integrados con otras aplicaciones

¿En que otros escenarios se mantendria?
En la adición de otros servicios no solo hogar y móvil sino tambien podria incluirse por ejemplo el segmento empresarial

Resuelve
Ingreso y control de calificaciones de estudiante para un Colegio.
Requerimientos no funcionales

• Acceso seguro al sistema

• Habilitar módulos dependiendo del rol de cada participante.

• El programa tendrá un CRUD de estudiantes, así como también de cursos y profesores.

• Se desplegará las estadísticas de cada curso, cada estudiante, etc.
  Cómo cambiaría su arquitectura?
  Actualmente se realiza el control de calificaciones de una manera manual y uno que otro archivo de excel, la ide es poder implementarlo en un entorno web, para que al catedrático se le pueda facilitar el ingreso de notas para sus estudiantes.
  ¿En qué otro escenario debería repensarse completamente?
  Este sistema no sólamente nos ayudará a llevar notas, si no que también podría ayudarnos en los escenarios de control de asistencia, control de suspensiones, hasta en el control de ingreso a la institución.
  ¿En qué otros escenarios se mantendría?
  También se podría mantener en un entorno móvil.

Sistema para administración de fondos de inversión
Resuelve:
Calcula los diferentes tipos de entradas, salidas, distribución y administración de dinero de un fondo de inversión colectiva
Requerimientos no Funcionales:

Se requiere autenticación de dos factores para ingresar
El sitio debe ser responsive
El tiempo de respuesta para cerrar un fondo debe ser inferior a 5 minutos.

¿Cómo cambiaría su arquitectura?

Apificaría su estructura de manera que se expongan de manera segura los diferentes servicios, eliminando los sistemas ordinarios de cliente servidor.

¿En qué otro escenario debería repensarse completamente?
En un cambio muy drástico de la legislación actual.

¿En qué otros escenarios se mantendría?
En escenarios donde los cálculos de cierre de fondos sean similares, por ejemplo en otros paises.

Sistema: Hangouts
Problema que resuelve: Comunicación a distancia entre personas
Requerimientos no funcionales:

• A la conferencia solo pueden ingresar personas que cuenten con invitación o link de acceso
• Para las personas que intenten ingresar a la conferencia con un correo que no esté asociado al dominio de la empresa se le debe solicitar permiso para poder acceder y el permiso solo lo puede conceder otra persona que esté dentro de la conferencia y a la vez cuente con el correo asociado al dominio de la empresa
• El sistema debe permitir comunicación por voz y texto y acceso a la cámara para transmisión de video en tiempo real
  Otro escenario: Asistencia remota en cirugías
  Cómo cambiaría su arquitectura en ese escenario: El sistema debería cambiar atributos de calidad, como por ejemplo mantener la videollamada incluso ante una caída de internet
  Otro escenario en el que debe repensarse completamente: aula virtual de clases
  Otro escenario en el que se mantiene: cualquier app donde se requiera comunicación a distancia

Sistema: Aplicación para compra-venta de propiedades.
Problema que resuelve: Eliminia los intermediarios y reduce mucho los costos en las operaciones inmobiliarias.

Requerimientos no Funcionales:
Conectar directamente a compradores y vendedores.
Asegurar un entorno seguro a traves de validacion de identidad y documentación de las propiedades.
Transparencia en los costos y servicios que ofrece la app.
Ofrecer lugares y asesoría especial para la gestión de las transacciones.

Producto reutilizable:
Podría adaptarse muy bien a la compra venta de otros activos con valores altos y que requieren documentación especial. Como la compra venta de automotores, eliminando intermediarios y mejorando los precios.

¿Cómo cambiaría su arquitectura?
La arquitectura de la app esta modulada en diferentes feautures. El chat se convierte en un punto importante de recoleccion de datos para aprender más del negocio y ofrecer nuevas caracterisitcas a los propietarios y potenciales compradores. Estas nuevas funciones (a descubrir en producción) tienen que ser desarrolladas como pequeñas apliaciones que se conecten con la app.

¿En qué otro escenario debería repensarse completamente?
En un sistema de compra venta donde el modelo de negocio requiera la intervención de alguien del producto.

¿En qué otros escenarios se mantendría?
En el escenario de compra venta de automotores y otros que requieran validación de documetación o similares.

Proyecto Upload:
Este sistema resuelve el problema de carga de informacion centralizada para distintos tipos de formatos de informacion de cada cliente.

Requerimientos no funcionales

• Seguridad de la informacion
• Seguridad del acceso del usuario
• Estabilidad de la aplicación en el proceso de carga y validación del archivo

¿Como cambiaria su infraestrctura?
Se realizaria una re-implementacion del proceso de selección de carga, para que el usuario solo cargue el archivo y el sistema proceda a analizar al descripcion del archivo y los permisos del usuarios, para permitirle cargar de forma directa el archivo, sin tener que seleccionar ninguna opcion de datos.

¿En que otro escenario repensarse completamente?
El sistema de inventario, el cual se desarrollo como un servicio de espera de carga, mientras puede realizar extraccion de datos desde proceso remotos.

¿En que otros escenario se matendria?
La solucion actual tiene varios puntos de mejoras, pero se puede desarrollar un mejor proceso de front-end.

Sistema Conocido:
Servicio WEB para recibir solicitudes de autorizaciones de procedimientos médicos.
El sistema resuelva la falta de oportunidad en la atención de necesidades de servicios médicos requeridos y que por contrato la empresa debe proveer de manera oportuna.
Requisitos no Funcionales:
Garantizar:
Acceso Restringido
Calidad: Exactitud, verificabilidad y completitud de la información recaudada por el sistema.
Autenticar la titularidad de los clientes (evitar suplantaciones).
Conexiones seguras.
Registro del acceso.
Como cambiaria la arquitectura actual:
Implementando la integración de ese servicio con el sistema de registro de los afiliados para determinar que el cliente es un cliente valido y que sus condiciones administrativas (activo y que haya pagado) le dan permiso de acceder al sistema.
Desarrolla un servicio de doble factor de autenticación.
Establecer la segregación de funciones y del acceso a la información de los usuarios del sistema, para garantizar la confidencialidad de la información médica de los pacientes.

Proyecto:
Plataforma digital que ayuda a las personas con deudas de tarjeta de credito a re negociarlas y liquidarlas.

Problema que resuelve:
Mitigar las deudas de tarjetas de credito que están en mora.

Requerimientos No Funcionales:
-Datos sensibles encriptados.
-Interacción en tiempo real.
-disponibilidad 24-7.
-Plataforma Web.

Producto Reutilizable:
-¿En que escenarios se mantendría?
Re-negociar deudas de cualquier otro tipo como por ejemplo: deudas escolares, deudas medicas, hipotecas… etc
-¿En que otro escenario debería repensarse?
Cuando el producto se introduzca a nivel global, las leyes de cada país-locación haría que se replanteara las formas de negociación, es decir restricciones diferentes
-¿Como cambiaría su arquitectura?
Tomando en cuenta el escenario de que cada país tiene sus propias leyes en cuanto al entorno financiero, re diseñar el sistema para que soporte y sea dinámico a los cambios de forma de negociación de cada país, sin que altere la lógica principal.

Reto: clasificación de requerimientos y análisis de riesgos.

Proyecto personal:

En mi día a día en la universidad, sigo un flujo de trabajo que me ha servido mucho este tiempo para sacar las mejores calificaciones. He notado que no todos los alumnos son así y que les cuesta administrar su vida escolar. Es por esto que cree un sistema que puede ayudar a muchas estudiantes, sobre todo en estos tiempos, en el que puedan administrar mejor su vida escolar online con herramientas y un flujo de trabajo que les garantizará menos estrés y más calificación.

Los principales problemas que resuelve este sistema son:

• Administración de horarios de clase
• Constante citación de textos online.
• Administración de materiales de trabajo para las asignaturas del alumno.
• Administración de las calificaciones de toda la carrera del alumno.

Requerimientos no funcionales.

• El sistema debe tener los temarios, planes de trabajo, asignaturas, semestres y carreras de la universidad en la que se implementará.
• La plataforma no funcionara como un intermediario entre profesor-alumno, esta solo se encargará de administrar la vida escolar del alumno.
• El sistema debe atender a las necesidades generales y no particulares de la vida universitaria, de preparatoria y de secundaria.

Si tuvieras que hacer de este sistema un producto re-utilizable en otros escenarios:

¿Cómo cambiaría su arquitectura?

• los módulos principales del sistema tendrían que generalizase para adaptarse a cualquier implementación posible.
• La interfaz tendría que volverse serverless para no depender explicitamente de un servidor especifico.
• Tendría que aumentar la seguridad independiente de cada entidad del sistema.

¿En que otros escenarios tendría que repensarse completamente?

• Al implementar el sistema a una escala global hay muchos riesgos que no se consideraron en su desarrollo local. Por lo que habría que rehacer muchos de los componentes del sistema considerando las problemáticas que pueden presentar los países en los que valla a ser implementado.
• En escuelas con sistemas no convencionales de enseñanza cabe la posibilidad de que no pueda ser implementado este sistema. Esto llevaría a una reorganización del sistema si se planea llegar también a estos lugares.

¿En que otros escenarios se mantendría?

• Si se quiere implementar nuevas funcionalidades de baja complejidad, no tendría que reestructurarse el proyecto.
• Al mudar el sistema a alguna nube, lo único que debería cambiar es el servidor que se utilizaba antes, mientras que la interfaz se mantendría.
• Al momento de escalar el proyecto de forma no exponencial, no debería de modificarse el sistema, simplemente el hardware en el que corre.

**Sistema: ** Plataforma para capturar la asistencia al comedor de la empresa.
**Problema: ** Capturar la asistencia de miles de empleados de manera simultánea en los diferentes comedores de la empresa ha llegado a ocasionar retrasos en la conexión a la base de datos del servidor MS SQL.
**Requerimientos no funcionales: ** Reporte de asistencias
**¿Cómo cambiaria su arquitectura?: ** Implementar una base de datos dentro de la arquitectura misma del sistema, la cuál servirá como el almacenamiento de los registros de cada estación para que al final del turno, se ejecute una tarea que lo replique a MS SQL de manera masiva.
**¿En qué otro escenario debería repensarse completamente?: ** Si se quisiera alertar de que un mismo número de empleado se registrara en dos estaciones diferentes el mismo día al mismo turno en tiempo real.
**¿En qué otros escenarios se mantendría?: ** Para capturar la asistencia de los empleados al comedor aun sin conexión a la red interna de la empresa, ya que todo estaría en la base de datos local de SQLite

Sistema de Gestión de Facturas SGF
Herramienta que permite realizar gestión contable de facturas, asi como creación de empresas y terceros. Permite la generación de cálculos y reportes.

Requerimientos no funcionales:

• La herramienta debe ser amigable, los usuarios deben poder interactuar con el sistema de forma fácil y rápida.
• La herramienta debe ser segura, solo los usuarios registrados y habilitados deben poder usarla.
• La herramienta debe ser usable, deben existir manuales y guías de usuario.

¿Cómo cambiaría su arquitectura?
Dependiendo de los ajustes que requiera el nuevo sistema, modificaría las diferencias capas de la arquitectura para que se adapten a los nuevos requerimientos. La arquitectura de la aplicación se compone de las capas de dominio, aplicación e infraestructura, lo cual facilita los cambios.

¿En qué otro escenario debería repensarse completamente?
En aquellos en los cuales las reglas del negocio principales de la herramienta no sean aplicables.

¿En qué otros escenarios se mantendría?
En escenarios muy similares que consistieran en gestión y procesamiento de información persistida en un motor de base de datos.

**Sistema de pasaje para autobus y contabilidad
**
Problema que resuelve:
Contar la venta de boletos de las unidades del dueño y tener un registro de los gastos de las unidades y pago a empleados.

Requerimientos no funcionales:

• Cobrar el pasaje mediante el uso de celular con nfc
• Contabilizar pasaje en caso de cobro en efectivo
• Registrar ubicación de la unidad usando el gps del celular en la unidad
• Enviar reporte de lo vendido desde el celular de la unidad
• Agregar gastos y pagos de conductores desde web
• Generar en reporte del día de la unidad en en web

¿Cómo cambiaría su arquitectura?
Cambiaria a dependencia de requerimientos específicos para la contabilidad que vayan mas haya de ingresos y egresos

**¿En qué otro escenario debería repensarse completamente?
**
Cuando un cliente requiera la forma de pago no sea solamente por nfc o efectivo, como por ejemplo tarjeta de credito/debito