Reto: Clasificación de requerimientos y análisis de riesgos

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.

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.

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

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.

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.

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

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

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 gestión de entrada y salida de empleados

Problema:

1. Errores por ingesta de datos manual, tanto en remuneraciones como cobro a empresas.
2. Poco tiempo para realizar otras actividades.
3. Descentralización de datos

Solución:

1. Automatización de procesos.
2. Cálculo automatizado de remuneraciones.
3. Cálculo automatizado de cobro a empresas.

RNF:

• Ver el ingreso y salida en tiempo real.
• Conexión remota a través de una base de datos en un servidor externo.

SISTEMA DE SINCRONIZACION DE DATOS DE VEHICULOS DESDE ONPREMISE A LA NUBE
Problemas Resueltos:

• Sincronizacion de datos, fotos y documentacion de vehiculos desde onpremise hacia cloud,
• Validacion de información disponible para sincronizar.
• Validacion de información completa.
• Validacion de disponiblidad de servicio cloud.
• Reintentos.
• Envio de notificaciones de error.
• Integraciones con otros micorservicios (Notificaciones).

Requerimientos no funcional:

• Diponibilidad.
• Seguridad.
• Escalabilidad

¿Cómo cambiaría su arquitectura?
Si tuviera integraciones con otros servicios Cloud, se tendria que vailidar la manera de como integrarse con otros Cloud

¿En qué otro escenario debería repensarse completamente?
En caso de que el origen de datos no sea Onpremise, se tendria que adaptar al nuevo origen de datos que bien podria ser algun servicio web (API) bien sea desplegado en on premise o cloud.

¿En qué otros escenarios se mantendría?
Escenario: Inetergacion con otros servicios cloud o con otras plataformas e-comerce.

Aplicación de geolocalización para delivery de ultima milla

Problema que resuelve:
Conocer en tiempo real la ubicación de las entregas.

RF.

• Capturar registro fotográfico de las entregas.

• Envía la ubicación de donde se registró una entrega.
  Permite guardar un historial de entregas.

RNF.

-Cifrado de la conexión entre la app y el servidor.
-Tutorial dentro de la app para conocer su funcionamiento.
-Disponible para IOS y Android.
-Disponible 24/7.

Sistema: Sistema de asignacion de cargas de trabajo
Problema que resuelve:

• Permite llevar un registro historico de las cargas de trabajo asignada
• Evita la repeticion de una misma funcion
• Permite ver los datos de una forma mas organizada
• Permite ver la disponibilidad de cada empleado
  RNF
• Ver asignaciones en tiempo real
• Conexion con una base de datos
• Interoperabilidad con otra herramienta de analisis
• Accesos limitados de acuerdo a permisos

Para hacer el sistema reutilizable
¿Cómo cambiaría su arquitectura?
Implementando la automatizacion del proceso para evitar trabajo manual

¿En qué otro escenario debería repensarse completamente?
Asignaciones de cargas de trabajo que no esten representadas de forma numerica

¿En qué otros escenarios se mantendría?
En cualquier ambiente laboral donde se necesite asignar una funcion en especifico
a cada empleado

Sistema seleccionado: Un sistema de gestión de contenido (CMS) como WordPress.

Problemas que resuelve este sistema:

1. Creación y gestión de contenido en línea, como páginas web, blogs y galerías multimedia.
2. Administración de usuarios, roles y permisos para controlar el acceso al contenido y funciones del sistema.
3. Personalización de la apariencia y funcionalidad del sitio web mediante temas y complementos.

Requerimientos no funcionales de este sistema:

• Disponibilidad: garantizar el acceso continuo al contenido y funciones del sistema.

• Escalabilidad: permitir el manejo de un aumento en la cantidad de contenido, tráfico y usuarios.

• Rendimiento: tiempos de respuesta rápidos en diferentes dispositivos y navegadores.

• Seguridad: proteger la información y los datos de los usuarios de accesos no autorizados.

• Privacidad: cumplir con las regulaciones de privacidad de datos aplicables.

• Usabilidad: fácil de usar y navegar, incluso para usuarios no técnicos.

• Personalización: permitir a los usuarios personalizar la apariencia y funcionalidad.

• Extensibilidad: facilitar la adición de nuevas funcionalidades e integración con otros sistemas.

Adaptación del sistema para que sea un “producto reutilizable”:

1. Cambio en la arquitectura: Para adaptar el CMS a otros contextos, la arquitectura podría volverse más modular y orientada a microservicios. Por ejemplo, se podrían separar la gestión de contenido y la gestión de usuarios en dos microservicios independientes, lo que permitiría una mayor flexibilidad y personalización.

2. Situación en la que sería necesario replantearlo por completo: Si el CMS se utilizara en un entorno con requisitos de tiempo real y alta velocidad, como un sistema de transmisión de video en vivo, sería necesario replantear la arquitectura para adaptarse a las necesidades de rendimiento y latencia. En este caso, se podrían utilizar tecnologías como WebRTC y CDN para garantizar una transmisión en tiempo real y sin interrupciones.

3. Contextos en los que se mantendría sin cambios: El CMS podría mantenerse sin cambios en la mayoría de los contextos donde se necesita crear y gestionar contenido en línea, como blogs personales, sitios web corporativos y portales de noticias. La arquitectura y funcionalidades existentes son lo suficientemente flexibles para adaptarse a estos casos de uso sin modificaciones significativas.

Sistema: Modulo de Admisión Tarjeta de Crédito.

Problema que resuelve:

• Evaluación de Morosidad del Prospecto
• Calculo de puntuación para el producto
• Validación Biométrica
• Envió de notificación (SMS)
• Consulta Cotizaciones
• Valida Carga Financiera
• Asigna producto y cupo
• Creación del cliente
• Activación de seguros
• Embozado de la tarjeta
• Asigna pines y activas la tarjeta

Requerimientos No Funcionales:

• La conexión al sistema debe ser solo desde la red de la organización.
• Acceso restringido a perfiles específicos de la organización.
• Realizar el embozado de la tarjeta y su activación en el momento, evitar que el cliente vuelva otro día a retirar la tarjeta.
• Integración segura con los proveedores.

Producto reutilizable:
¿Cómo cambiaría su arquitectura?

• El actual sistema está desarrollado PHP y Oracle (BD compartido con más sistemas) y su infraestructura se encuentra en OnPremises, por lo tanto, implementaría un modelo de base datos solo para este sistema desacoplando de las BD legado en Oracle, este nuevo modelo lo implementaría en PostgreSQL por sus ventajas principalmente en costo y flexibilidad. También se desarrollaría una capa de Apis en NodeJs ya que este framework es más optimo en rendimiento y escalabilidad, estas API manejaran el CRUD a la base datos y serán consumida desde un FrontEnd desarrollado en Angular, ya que este framework nos da un set de herramientas acordes a nuestro sistema.
  Por el lado de la infraestructura lo implementaría en una de las 3 grandes nubes (Azure, AWS y GCP) especialmente por su pago por uso ya que este sistema se utilizará en los horarios de atención de la tienda, en ese caso sería Azure ya que posee diversos recursos PaaS que nos facilitan los despliegues de nuestros desarrollos además posee herramientas de seguridad y gestión de API y principalmente la experiencia de los equipos trabajando con Azure.

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

• En el caso de implementar una aplicación móvil para los ejecutivos, se deberían utilizar herramientas adicionales para realizar ajustes especialmente en el Frontend.
• En el caso de abrir la opción de Admisión Online donde el cliente pueda por sí solo realizar el flujo de admisión, en este caso se debería implementar un nuevo front adicional, ajustar las Apis existentes y también incorporar nuevas estrategias de seguridad en el desarrollo y Cloud.

¿En qué otros escenarios se mantendrían?

• En lo personal no lo mantendría por lo problemas mantención actuales, pero se podría mantener si el cambio no es rentable es base a los ingresos del área dueña del sistema o si el negocio no tiene pensado potenciar esta área.

SIST ASIGNACION DE INTERVENCIONES EN FORO PUBLICAS

RESUELVE: asignar de forma eficiente discursos, demostraciones e intervenciones en foros

ARQUITECTURA:
varias bases de datos:

base de nombres: contiene nombres de participantes, fechas de cada intervención.

DB histórico de cada asignación: tiene una relación de cada lección ejecutada desde el año 2022 hasta la fecha

DB lecciones: cada asignación tiene una lección de oratoria, en esta base se relaciona y se marca automáticamente cada participante con cada lección que haya realizado

DB combinaciones: los participantes suelen hacer asignaciones de a dos, para que no se repita pareja se crea esta base.

CUADRO MENSUAL DE ASIGNACIONES: de acuerdo a la información suministrada en las bases anteriores, y teniendo en cuenta la programación mensual suministrada por un agente externo se asigna de forma manual a los participantes.

**CAMBIOS EN LA ARQUITECTURA: **

• mayor automatización

• que el sistema sugiera automáticamente quienes deben participar de acuerdo a su progreso

• que muestre alertas

• que se integre automáticamente con la programación mensual y que cree un nuevo cuadro mensual cada mes

**REPENSARSE: ** se replantearía en caso de que tengamos que integrar con otro tipo de asignaciones

SE MANTENDRIA: si se aumenta la cantidad de estudiantes

1. Sistema: SISTEMA PARA EL ALQUILER DE CABAÑAS

2. Problemas que resuelve:

• Permitir a los propietarios de cabañas ofrecerlas para alquiler.

• Brindar un catálogo de cabañas a los viajeros interesados en alquilar viviendas de este tipo.

**3. Requerimientos no funcionales: **

• Sólo los usuarios autenticados podrán ponerse en contacto con los propietarios de las cabañas. (Seguridad)

• El sistema deberá estar disponible veinticuatro horas, siete días a la semana. (Disponibilidad)

• Se deberá notificar a los propietarios de las cabañas cuando una publicación suya sea vista por un usuario. (Rendimiento)

4. ¿Cómo cambiaría su arquitectura?

Actualmente el proyecto está estructurado con dos módulos: En backend como un monolito con un patrón de arquitectura de modelo-vista-controlador implementado mediante Springboot, que atiende peticiones para usuarios, cabañas y reservaciones. Mientras que en frontend está desarrollado en React y SPA.

El principal cambio se tendría que dar en el backend, rompiendo el monolito y creando micro servicios para cada uno de los dominios: usuarios, cabañas y reservas. Además de dejar de lado el patrón de modelo-vista-controlador que está muy ligado al framework, para darle paso a la arquitectura hexagonal que está centrada en el dominio y dejaríamos de depender de las implementaciones que nos sugiere el framework.

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

En caso de que el proyecto tenga éxito y su escalabilidad y mantenimiento se vuelvan inmanejables, deberían darse los cambios expuestos en el ítem anterior.

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

Si el proyecto se mantiene con un bajo perfil y puede ser mantenido por un equipo pequeño de desarrollo, aún así, es complejo la mantenibilidad de un monolito con más de una persona trabajando sobre él. Así que, los cambios en arquitectura deberían darse casi en cualquier escenario.

**Sistema: ** Sistema de Gestión de procesos administrativos y financieros en una empresa de transporte.

Problema que resuelve:

• Gestiona el proceso de cotizaciones de viajes

• Gestion el ingreso de facturas por pagar y por cobrar.

• Gestión de reportes de ventas.

RNF:

• Mejor visibilidad de los reportes de cotizaciones.

• Mejor visibilidad de la data obtenida de sistemas externos como el TMS.

¿Cómo cambiaria su arquitectura?
Actualmente este sistema esta construído bajo una arquitectura MVC y desplegado sobre un servidor AWS Lightsail. Una forma de cambio de arquitectura sería optar por una basada en microservicios ya que el sistema en su etapa evolutiva está requiriendo mayor funcionalidad y por ende, son mas servicios que se deben implementar. Además, es necesario desacoplar servicios conectados a sistemas externos como TMS o como otro sistema de facturación electrónica para explotar los recursos disponibles de Aws.

¿En qué otro escenario debería repensarse?
Cuando el rubro del tipo de transporte cambia, por ejm: Servicios de transporte de personas (taxis) o cuando la organización no es dueña de los vehículos.

¿En qué otros escenarios se mantendría?
En otras organizaciones que realicen transporte de mercadería de valor y la misma organización sean dueñas de los vehículos.

Sistema: Sistema POS para CYD Modulares
Problemas que resuelve:
* Gestión de productos
* Gestión de clientes
* Facturación
* Gestión de empleados
Requerimientos no funcionales:
* Dashboard para control de ingresos

Para hacer el sistema un producto reutilizable …
¿Cómo cambiaría su arquitectura?
* Escalando a servicios cloud y sea accesible desde
cualquier endpoint.
* Agregando servicio de códigos de barras para control de
inventario

¿En qué otro escenario debería repensarse completamente?
* Se puede generalizar para cualquier tipo de negocio de
venta de productos

¿En qué otros escenarios se mantendría?
* Cambiando los servicios de bases de datos relacionales

Sistema para gestión de campañas de marketing automatizadas

Problema que resuelve:

• Se evita enviar las comunicaciones a mano
• Se evita crear un correo a la vez
• Permite la comunicación por correo y por mensajería instantánea
• Permite importar la lista de contactos desde un archivo
• Permite devolver la cantidad de errores filtrados por fila del Excel de importación
• Permite la visualización de los mensajes

Requerimientos no funcionales

• El archivo de importación debe ser Excel
• Las comunicaciones de correo electrónico deben realizarse con AWS SES
• Debe crearse una bitácora con los contactos enviados por cada campaña con el resultado del envío
• Debe hacerse un reintento si el envío falla
• Si al reintento falla otra vez, se genera una lista de contactos que dieron error y se muestra como resporte después del envío de la campaña

Producto reutilizable

Cómo cambia su arquitectura

Si se desea que el producto sea reutilizable, se debe considerar que muchas empresas pueden utilizarlo, por lo que se consideran los siguientes aspectos:

• Se debe crear un nuevo componente de empresas, que maneje la autenticación y autorización de los colaboradores de cada empresa
• Se debe asociar las campañas con la empresa y guardar las listas de contactos para campañas futuras.
• Se debe generarlizar los correos electrónicos por cualquier servidor de correos o para que la empresa pueda gestionar su propio SMTP
• Se debe crear un número de celular propio de WhatsApp para que las comunicaciones por mensajería instantánea para que muestre el nombre de la empresa
• Se debe considerar el envío de mensajes por otros medios como: SMS y Telegram

En qué otro escenario debería repensarse completamente

• Si las empresas piden abarcar todo el proceso de ventas desde la captación de leads, se debe pensar en los principales canales de contacto: redes sociales, contacto directo, llamada, sitio web, etc.
• Si las empresas solicitan la creación automática de textos y multimedia para las campañas, se debe pensar en de qué forma se generar lo necesario para que una campaña sea exitosa

En qué otros escenarios se mantendría

• Las empresas piden añadir un reporte de éxito de apertura de los correos
• Las empresas piden un reporte con todos los contactos que no abrieron la comunicación para hacer reintentos
• Las empresas piden tener varios remitentes
• Las empresas piden tener un conjunto de plantillas de comunicaciones según grupos de campañas (por temporada: navidad, escolar, fiestas patrias, etc.)

sistema de gestión de pedidos y gestión de envíos en un puntos de comidas rapidas.

-en un principio desarrollaría una plataforma online para gestionar desde cualquier punto o/U desde cualquier equipo un nodo de gestión.

-se utilizaría la plataforma multifuncional para gestiones de comida rápida y otro tipo de restaurantes con sucursales. los cuales se verían beneficiado por el uso de una plataforma versátil y reutilizable también por supuesto reconfigurable y personalizada para cualquier tipo de negocio que la solicitara,

-por ovias razones de seguridad y capacidad de procesamiento se alojaría en un servidor remoto si necesidad de al adquisición de pesados y costoso equipos
así se utilizarían los sistemas predispuesto para servicios online como los Microsoft y Amazon.

Proyecto

Sistema de registro de objetos perdidos de estudiantes de una universidad

Que problema resuelve

Generar un mejor control sobre la información de los objetos perdidos, como fecha y hora de recogida y a quien se le entregan. Ademas, elimina el uso de planillas para el guardado de datos implementando una base de datos.

RNF

• El sistema debe guardara fecha y hora en la que el objeto entro en el registro.
• La aplicación web debe tener un diseño claro e intuitivo
• Cada objeto debe tener una foto asociada para facilitar su reconocimiento
• La base de datos debe reflejar el estado del objeto, si fue entregado o si fue embodegado.

Si fuera reutilizable

Como cambiaría su arquitectura

Se puede implementar un sistema en el que las personas o estudiantes puedan ingresar y saber que objetos se encuentran perdidos actualmente. Aunque esto tendría mayor riesgo de que alguien distinto al dueño reclame el objeto.

En que otros escenarios debería repensarse completamente

Se debería repensar en el caso de que se deba tener registro con QR o un código de barras para cada objeto, o en el caso de que se tenga una manera de identificar quien es el dueño del objeto.

En que escenarios se mantendría

Se mantendría en escenarios de empresas, colegios o diversas organizaciones que requieran un sistema para registro de objetos perdidos.

.

Sistema de inventario y facturación
El sistema en cuestión realiza la gestión en varios modulos, productos, proveedores, facturas, inventario, bodegas, etc. Debe ser implementado para varias empresas (Multiempresas).

Problema que resuelve:

• Gestión de Productos
• Control de productos caducados
• Gestión de Facturas de compra y ventas
• Gestión de stock por bodegas
• Gestión de Clientes y contactos

Requerimientos no funcionales, son el firmado de la factura en xml, respaldos cada 24 horas, tiempo de respuesta inferior a 5 segundos para la mayoria de endpoints.
.
¿Cómo cambiaría su arquitectura?
Actualmente el sistema es web, y cuando se crea una nueva empresa, se crea una base de datos nueva por cada una, lo que mejoraría es crear solo una base de datos en la cual se coloque una tabla de empresas y se enlace al resto mediante una relación, el respaldo se optimizaría y las consultas serían más rápidas.
.
¿En qué otro escenario debería repensarse completamente?
El escenario sería cuando se necesite obtener un reporte global, tratando de consolidar información sería muy complicado si las base de datos están separadas por empresas.
.
¿En qué otros escenarios se mantendría?
El escenario donde se mantiene es que cada empresa no necesite respaldos, solo cuando ellos los requieran.

Sistema de apoyo a la gestión de los diferentes productos que ofrece cierto tipo de entidades financieras.

El Sistema permite el registro de productos y realiza el procesamiento que permite cálculos de rendimientos y cobro de comisiones para aquellos que aplique. Así mismo permite hacer transacciones de consignaciones, retiros, transferencias teniendo en cuenta las regulaciones impositivas de manera muy parametrizable.

Requisitos no funcionales:
Seguridad, tiempo de respuesta, alta disponibilidad, mantenibilidad.

El sistema es bastante reutilizable por el alto nivel de parametrización que maneja permitiendo variar su comportamiento para las entidades que así lo pudieran requerir. La tecnología sobre la que está construido permite que haya clientes on-premise y otros con despliegue en la nube.

El sistema debe repensarse a partir de su modelo de datos, debido a que al ser centralizado (era una de sus características más valoradas), es un monolito en lo que modelo de datos se refiere. El principal cambio de arquitectura que requiere es llevarlo posiblemente a un modelo de datos
distribuido que permitiera escalabilidad para mejora de procesos que así lo requieren, una mayor tolerancia a fallos, y a largo plazo un cambio de tecnología que permitiera un cambio en el modelo de consumo de recursos de infraestructura variable (en la nube posiblemente AWS) y así mismo implementar un pago por uso de recursos y no tarifas full permanente.

Si hubiera alguna sugerencia, se agradecería que lo pudieran enviar por este medio

Entender el problema

Problema

Necesito una aplicación para realizar operaciones aritméticas básicas como algunos cálculos de funciones básicas, y así ahorrarme tiempo para calcular

Idea: ¿Qué queremos resolver?

• Cálculos algorítmicos
• Almacenamiento del historial de cálculos
• Usar una notación matemática sencilla
• Facilidad y fluidez de uso de la aplicación

Criterios de éxito

• El usuario se siente cómodo de realizar muchas operaciones en la calculadora
• Los cálculos están correctos

Requerimientos

Requerimientos no funcionales (RNF)

• Uso de la memoria local
• Interfaz intuitiva
• Rapidez en los cálculos
• Aplicativo multiplataforma con tecnologías web

Evolución

¿Cómo cambiaría su arquitectura?

• Cuando se quiera integrar con API’s
• Añadiendo más funcionalidades que no sean operaciones; es decir, que requieran de mayor trabajo interno

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

• Si se desea optimizar la aplicación
• Si se busca portabilidad de la misma
• Aumento de los equipos en el desarrollo del software
• Posibles riesgos de alto impacto

¿En qué otros escenarios se mantendría?

• Cuando no se desee implementar características muy notables
• Los errores en la app no son tan riesgosos

Sistema de gestion de paqueteria:
Objetivo principal: Administracion de las unidades que llegan a bodega y su distribucion hacia los puntos finales
Problemas a resolver:
- Registrar todos los paquetes que llegan a las bodegas y los categoriza segun lugar de bodega
- Asignacion de repartidores de ciertos paquetes para llegar a su destino
- Generacion de reportes
Requerimientos no funcionales:
- Sistema siempre disponible
- Gestionar grandes cantidades de paquetes a grandes cantidades de repartidores
- Generacion en tiempo real de los reportes de forma facil y rapida

¿Cómo cambiaría su arquitectura? Dividiria el producto dependiendo de las funciones en diferentes microservicios para usuarios en particular del sistema, como es el sistema de alta de paquetes, gestion de almacen, gestion de despachos, gestion de recepcion y generador de reportes
¿En qué otro escenario debería repensarse completamente? Si se esta generando una inestabilidad en el sistema debido al aumento de la actividad del sistema, en especial de las consultas básicas hasta la generación de reportes que es el que más consume recursos. Tambien por la optacion de otro sistema para la generacion de recepcion de paquetes que es de un tercero, se cambie a otro proveedor. Por ultimo, en dado caso que se migre a una aplicacion movil que pueda usar los usuarios
¿En qué otros escenarios se mantendría? Si el sistema es estable y cumple con las funciones basicas. Solo al menos que quieran el uso de microservicios

Sistema de registro de un hotel.

Problemas a resolver:

• Generar un registro y control de las personas que se hospedan en las instalaciones.
• Generar facturación para control de ingresos (en términos de dinero)
• Control de la disponibilidad de habitaciones ya sea:
  • Disponible
  • Ocupada
  • En mantenimiento.

Requerimientos no funcionales:

• Seguridad. La protección de los datos personales.
• Disponibilidad de todos los métodos de pago.

¿CÓMO CAMBIARÍA SU ARQUITECTURA?:
Se podría generar un pre-registro por medio de un canal web para aumentar la velocidad del proceso de registro, generando mayor bienestar al huésped al evitar gastar tiempo en dicho proceso, una implementación de pago anticipado por medios digitales.

¿EN QUÉ OTRO ESCENARIO DEBERÍA RE PENSARSE COMPLETAMENTE?:

Al cambiar de rubro o aplicar a un público más joven, con mayor contacto tecnológico y uso de los canales digitales para realizar pagos.

-¿EN QUÉ OTROS ESCENARIOS SE MANTENDRÁ?:

En caso de ser usado en el rubro hotelero o de hostelería.

Me parece que este reto no es congruente con lo que se ha visto hasta ahora 😦 las preguntas resultan muy amplias y no siento que el contenido ahora este momento haya aportado las herramientas necesarias para resolverlo. Un ejemplo con el profe resolviéndolo antes habría sido de gran ayuda (Quizás esto se encuentre más adelante,)

Startup de logística:

Optimiza rutas de entregas para ayudar hacer más eficientes los envíos y/o rutas de servicio.

** RNF
**

• Actualización en tiempo real del estado de la entrega
• Generación de reportes sobre las entregas
• Diferentes opciones de configración de rutas

**¿Cómo cambiaría su arquitectura?
**
Separaría cada las responsabilidades de cada dominio en microservicios para tener una mayor mantenibilidad.

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

¿Y si se abarcaran rutas aéras también? Actualmente solo se trabajan con medios terrestres. Con rutas aéreas el sistema debería estar más preparado para un mayor número de cálculos debido a que las distancias aéreas son mucho más extensas.

Sistema de control de obras eléctricas
El objetivo de la aplicación es controlar la cantidad, presupuesto y tiempo de todas las obras que se entregan a una empresa contratista, encargada de ejecutar dichas obras de mantenimiento y crecimiento en el sistema eléctrico.
Requisitos no funcionales

• Alta disponibilidad para todos los usuarios que gestionan obras.

• Alta velocidad para realizar consultas y presentar la información a los usuarios finales.

• Permita controlar la concurrencia entre los usuarios que acceden a la aplicación.

• No permitir el acceso a equipos no autorizado en el control de Azure.

Un producto reutilizable.
Actualmente es una aplicación desarrollada en VBA, conectada a listas de SharePoint, para mejorar la utilización de este producto, se propondría una aplicación web con back desplegado en MS Azure o AWS (por los convenios de la compañía con estas corporaciones). Se realizaría una aplicación enfocada en satisfacer la seguridad de la información, con la menor afectación en la concurrencia y latencia.

¿En que otro escenario debería repensarse completamente?

• En el caso que se requiera realizar una aplicación móvil, que permita parte del control de obras y esta deba usarse en lugares donde la señal del internet no llega.

• También en caso de querer utilizar la aplicación para controlar gestión de obras eléctricas a nivel de construcción de edificios.

¿En que otro escenario se mantendría?

En caso de que se requiera replicar el modelo de control de obras en diferentes empresas dedicada a la distribución de energía eléctrica y en las cuales sus operaciones técnicas son ejecutadas por una o varias empresas colaboradoras.

Sistema: API para generar onboarding a una aplicación de firma electrónica por medio de biometrias
Problema que resuelve: Registro de datos de usuario por medio de sus biometrias (facial, dactilar, lectura INE) para permitir la firma electrónica de forma automática sin intervención de un tercero.
Requerimientos No Funcionales:
-Disponibilidad de API para su consumo desde app móvil
-Que el usuario cuente con la app móvil configurada y acceso a internet

Producto reutilizable:
Desacoplar los servicios que consumen cada una de las biometrias en diferentes APIs

¿Cómo cambiaría su arquitectura?
Establecer microservicios disponibles por cada biometria, ya que la arquitectura actual, solo publicaba un servicio.

¿En qué otro escenario debería repensarse completamente?
En escenarios que la biometria dactilar no aplicará, en caso de perdida de miembros por parte del usuario.
En caso que el usuario tenga en proceso su INE y no la tenga para hacer su onbording.

¿En qué otros escenarios se mantendría
En el escenario que tengas todo lo necesario (INE, celular con camára, todos los dedos de las manos).

**Sistema: **Analisis con OCR para extracción de texto en documentos bancarios
Problema: Diariamente al banco llegan cientos de documentos y los empleados se ven obligados a analisar uno por uno dependiendo de los requerimientos que tenga un cliente en especifico. Este analisis de forma manual provoca llega tiempo y por ende en ocasiones genera entrega tardía de respuesta por parte del banco a sus clientes.
Requerimientos no funcionales: Disminuír tiempo de respuesta a los clientes del banco y a su vez tiempo en la respuesta que entrega el sistema no mayor a 5 segundos, también alta confiabilidad de la respuesta que entrega el sistema con el documento que se está analizando.
Para hacer de este sistema un producto reutilizable…
**Cómo cambiaría su arquitectura? ** Siendo sincera no cambiaría su arquitectura ya que actualmente esta en una de microservicios, dos de ellos en nodejs para la administración de datos y uno en Python para el analisis de documentos con OCR, considero que la arquitectura montada es mantenible en el tiempo y se ha podido utilizar en algunos documentos y se podría segur utilizando para analisar otros.
En qué otro escenario debería repensarse? Este sistema no cuenta con reglas de negocio en su dominio, por ende creería que su arquitectura se debería repensar en caso de optar por aplicar alguna regla de negocio a un dominio en específico.
En qué otros escenarios se mantendría? Creería que este sistema como está desarrollado se podría mantener en escenarios en donde se busque analisar gran cantidad de documentos y que su analisis manual requiera un gran reproceso.

SISTEMA DE CONTROL DE TIEMPOS DE SERVICIOS EN AUTOMOTORES(MAINTANANCE PITS)
Problema que resuelve:

• Medir los tiempos que toma cada servicio
• Llevar un registro de todos los servicios de una placa vehicular
• Controlar varios servicios en simultaneo con los respectivos insumos utilizados
  Requerimientos no funcionales
• Inicio de sesion
• Busqueda de servicios en curso
• Panel de navegación
  Como cambiaria su arquitectura
• Repensaria la arquitectura de backend de un monolito a una de microsrevicios
• Implementaria un modelo de base de datos relacional
  En que otro escenario deberia repensarse completamente
• En el escenario de una aplicacion de escritorio
• En el escenario de una aplicacion mobil
  En que otro escenario se mantendria
• Por el momento solo en el escenario actual se mantendria

System: On-demand Companies Data Scraper
Solutions:

• Scrape companies’ data
• Export data into a CSV
• Import a CSV with the companies to scrape
• Show companies listed on a website

RNF:

• Scrape data as fast as possible
• The system has to be horizontally scalable
• The cost of the execution has to be as cheaper as possible

To make this system reusable, How It must change its architecture?

• Containerizing in docker each scraper
• Preparing a cloud formation for the EKS image

In which other case this architecture must be rethought?

• in the case, we do not have a limit to scrape

In which other case this architecture would keep it the same

• U*sing Document DB from AWS instead of MongoDB

Proyecto: Sistema de Gestión y administración para bares y restaurantes.
Problema que resuelve: Facilita la gestión y control de caja, inventario, propinas, reservas y lista de reproducción de canciones.
Cómo cambiaría su arquitectura?: Modularizando e independizando cada módulo por microservicios.
¿En qué otros sistema debería repensarse?: En otros negocios con dinámicas diferentes en las que los procesos requieran de otras variables o funcionalidades.
¿En qué otros escenarios se mantendría?: En miPymes con venta de productos que tengan problemas en la gestión de su caja e inventarios como tiendas.

SureService es una aplicacion que gestiona la contratacion de servicio de tecnicos, como gasfiteros, electricistas, informaticos, etc.

Requisitos No Funcionales:

• Comunicacion a travez de un chat en tiempo real mediante una red de internet
• Centro de ayuda implementado con un chatbot que resuelva dudas de manera segura a travez de inteligencia artificial
• Cifrado de contraseñas al momento de realizar la autenticacion
• Restriccion de peticiones a travez de un token unico de autenticacion de datos.

¿Cómo cambiaría su arquitectura?
La arquitectura la haria con microservicios, ya que la aplicacacion inicialmente esta realizada de forma monolitica, pero seria mas conveniente migrar a microservicios, ya que esto nos permitira tener un mejor mantenimiento de cada servicio y prevenir fallos en el futuro
¿En qué otro escenario debería repensarse completamente?
La aplicacion se tendria que replantearse al momento de realizar la aplicacion movil o web, por ejemplo la primera, si se ha hecho en un solo sistema operativo, derrepente pensar expandirse a otros sistemas operativos o realizar con un framework multiplataforma. Y en la parte web, tratar de pensar en una arquitectura mas escalable, implementando microservicios
¿En qué otros escenarios se mantendría?
Migrando de monolito a microservicios

Sistema: PLATAFORMA DE ATENCIÓN EN SALUD

Problema que resuelve:
Registro de la atención total de un paciente desde el agendamiento hasta la generación y custodia de la historia clínica.

2.- Requerimientos no funcionales
El sistema debe valida que tipo de usuario se conecta
El sistema debe comunicar a cada usuario según su rol
El sistema debe ser seguro y validar que el que firma la atención sea el propietario de la cuenta

3.- ¿Cómo cambiaría su arquitectura en caso de que sea un producto reutilizable?
La plataforma es modular, lo que permitirá el cambio de la misma para su crecimiento y ajuste según la entidad que la requiera.

4.- ¿En qué otro escenario debería repensarse completamente?
En caso que se realice un cambio de la tecnología usada.

5.- ¿En qué otro escenario se mantendría?
Una nueva versión dirigida a la atención directa en consultorios médicos, es decir que solo atienda a profesionales de la salud.

SISTEMA DE GESTION PARA UNA CLINICA
Problema que resuelve:

• Administración y distribución de los pacientes con el medico asignado teniendo Historial clínico almacenada en el sistema para visualización de los médicos y la receta imprimible y almacenada en el sistema

RNF:

• Gestión de triaje medico en enfermería previo a cada consulta.
• Gestión de los turnos de cada consultorio
• Gestión de historial clínico de cada paciente
• Gestión de la atención, diagnostico y tratamiento al finalizar la consulta

Para hacer el sistema un producto reutilizable …
Seria realizar el programa modulable para poder aumentar a futuro manejo de farmacia. Manejo de caja y facturación.

¿Cómo cambiaría su arquitectura?
Interconectando la base de datos para poder trabajarla via web y via app

¿En qué otro escenario debería repensarse completamente?
Cuando se requiera poder realizar solicitud de emergencia y comunicación interna del personal en tiempo real.

¿En qué otros escenarios se mantendría?
Aumento de modulos de funciones.

SISEUC

• Sistema de control de asignación y consulta de calificaciones.

• Aloja base de datos con información de alumnos y vincula sus credenciales
  -Página html con recursos php

• Permite la consulta desde cualquier dispositivo

-Haría al sistema actualizable en tiempo real

-La portabilidad del sistema, su eficiencia y su seguridad

Sistema: Aplicación Móvil (eCommerce)

Que Resuelve:

• Un canal más de ventas hacia el cliente
• Evitar filas y tiempo de espera de los clientes en horas pico y no pico
• Tienda siempre disponible 24hr / 7 días
• CRM de clientes para el seguimiento a futuro
• Promociones y Ofertas por canal digital
• Pagos con Tarjeta y contra entrega

Requerimientos No Funcionales:

• Credenciales de acceso
• Información del usuario Encriptada
• Comunicación estable con terceros
• Espejo de Base de Datos para Backup

Producto Reutilizable

¿Cómo cambiaría su arquitectura?

• Pondría una arquitectura HA(Alta Disponibilidad)
• Mejoraría los procesos de carga y consulta de información para hacerlos más eficientes y no consuman tantos recursos
• Mejoraría los enlaces de comunicación con terceros

¿En que otro escenario debería repensarse completamente?

• Homologaría la comunicación con terceros haciendo APIs y generando mensajería JSON

¿En qué otros escenarios se mantendría?

• En la codificación fuente del Frente (C#, JAVA)
• Base de Datos SQL Server

Sistema: Venta de megas para navegación en sitios de alto transfito como cenntros comerciales y aeropuertos, con cobertura Wifi, resuelve:

1. Navegar internet cuando existe baja cobertura de la red movil celular o esta congestionada.
2. Navegar cuando no posees datos en el saldo de tu dispositivo inteligente.
3. Navegar a alta velocidad.
4. Navegar desde computadores

Requerimientos no funcionales

1. Consumir API de los AP (access point)
2. Elaborar reportes de tráfico y crear LOGs de transacciones
3. Integracion de un Gateway para interacción con el usuairo via SMS

Cambios de arquitectura ( para re uso):

1. Desarrollo para microserficios y bloques funcionales
2. Crearia una libreria de APIs para distintos fabricantes de AP

Sistema: Gestión de datos maestros por una aplicación web para una empresa petrolera.
Problemas que resuelve:

• Centralización de gestión de dominios en una sola aplicación.
• Organización y etiquetado de los datos (gobierno de datos).
• Generación de un registro consolidado apartir de varias fuentes que tengan similar información.
  Requerimientos no funcionales:
• No guardar las contraseñas en base de datos, sino usando un servicio especial de la nube para esto (Azure Data Factory).
• Para los procesos ETL solo se puede usar las herramientas en la nube Azure Data Factory y Databricks.
• El sistema debe mostrar ciertos elementos en la interfáz gráfica de acuerdo al rol.
• Se debe tener una estrategia de ingesta de datos para solo cargar lo más reciente en cada ejecución y no todo el histórico de datos.

Para hacer el sistema un producto reutilizable
¿Como cambiaría su arquitectura?

• Actualmente es una app de escritorio, se puede desarrollar una versión móvil.
  ¿En que otro escenario debería repensarse completamente?
• Cuando haya cambios drásticos en el modelo de datos que utilizan los sistemas de información actuales de la empresa.
  ¿En qué otros escenarios se mantendría?
• Utilizando una arquitectura on-premise en lugar de la nube.

Sistema: SISTEMA DE GESTION DE RADIOGRAFIAS TU IAMGEN

Problema que resuelve:

• Rapidez de atención al usuario
• Mejor comunicación entre los involucrados en el proceso de las radiografias
• digitalización de las ordenes

Requerimientos no funcionales

• El sistema debe ser privado, solo se pueden conectar los trabajadores
• Ver las ordenes a tiempo real
• debe tener un tiempo de respuesta rapido, no mas de 5 segundos
• se debe conectar a traves de una vpn

Para hacer el sistema un producto reutilizable
Cambios en la arquitectura:

• utilizar un framework estandar, actualmente esta en un framework creado de 0 en php
• se pararía fisicamente el servidor de BD con el servidor web

Escenarios a repensar completamente

• no utilizar una vpn para no afectar la red de los equipos ya que se conectan a otros servidores que afectan si cambian su red
• utilizar metodología agiles y no tradicionales
• separar el fronted del backend mediante api rest
• usar otra tecnología en fronted como react y no JQuery

Escenarios a mantener

• rapidez del sistema
• seguridad del sistema
• mantener el lenguaje de programación (php) y el motor de BD

Sistema de toma de consultas médicas

• El problema que resuleve es ordenar la toma de horas para consultas médicas, asignándo un horario para el consultante e indicando las horas libres para que la tomen otros consultantes.
• Sus requerimientos no funcionales son establecer de forma segura que el usuario que toma una hora, sea realmente él (sin suplantación de identidad).
  .
  Si se tuviera que hacer de este sistema un “producto reutilizable” en otros escenarios:
  .
  ¿como cambiaría su arquitectura?
• Debería ampliar su almacenamiento, por ejemplo, si se quisiera integrar un registro histórico de toma de horas, diagnósitco, exámenes tomados, entro otros.
  .
  ¿En que otro escenario debería repensarse completamente?
• En el escenario en que exista una integración horizontal con los laboratorios y otros médicos (como una red centralizada de la información única del paciente)
  .
  ¿Que otros escenarios se mantendría?
  En la medida que solo sirva para agendar y no se necesiten más datos del paciente. Pues para ello se tendría que usar otro software.

Sistema: Sistema para la gestión eficiente del tiempo en hora de descanso.
Problema que resuelve: La comunidad estudiantil se está viendo afectada por no contar en algunos momentos con la oportunidad de hacerse a bienes alimenticios de los productos de la cafetería. Es por ello, por lo que algunos estudiantes en el espacio que tienen para tomar el descanso, no tienen acceso a los servicios de venta de la cafetería, porque la mayor parte del tiempo lo gastan en filas y el otro tiempo mientras se le realiza el debido despacho.
Como cambiaria la arquitectura: Haría un modelo de servicios que haga distribución de las necesidades de los diferentes actores involucrados y complementaria la app con servicios de terceros para la gestión de pagos.

En que otros escenarios debería repensarse completamente?
Estimo que se tendría que repensar la solución que permita involucrar a demás actores de la cadena estudiantil como directivos y docentes que posibiliten la opción de controlar la calidad de los productos ofertados por la cafetería, convendría, gestionar no solo las meriendas, sino el restaurante escolar y la gestión nutricional a cargo de especialistas.

En que escenarios se mantendria? Seguirá siendo una web application, desplegada en un proveedor cloud para el acceso de la misma desde cualquier dispositivo y ubicación.

Sistema:
ENTERPRISE RESOURCE PLANNING (ERP)

Resumen
Es un Software que ayuda a la empresa a administrar todo su negocio, respaldando la automatización y los procesos en finanzas, recursos humanos, cadena de suministro, ventas, adquisiciones y más.

Problemas que resuelve:
Mejorar la operación de la empresa en todo aspecto, integrando la gestión de pedidos que realizan los clientes, el movimiento de inventario, la contabilidad y el reparto de artículos en un solo sistema, así cada encargado del área tiene una visión de su trabajo menos propensa a errores.

Requerimientos no funcionales:

• Poder acceder desde cualquier dispositivo móvil.
• Que el sistema al realizar la venta envíe un correo electrónico con la factura.
• Los movimientos del sistema se deben ver reflejados en la cuenta de cada usuario.
• El software debe de poder realizar 50 transacciones por minuto entre las sucursales que tiene la empresa.
• Que cada usuario entienda fácilmente la navegación a través del software.

Cómo cambiaría su arquitectura:
Actualmente me encuentro involucrado en la transición de un software ERP que trabaja mediante un servidor local a uno basado en la nube de AWS. Adaptando las nuevas necesidades de la empresa en soluciones TI, enfatizando en la mantenibilidad, confiabilidad, escalabilidad y el rendimiento del software y así poder ayudar a las personas que lo usen a mejorar sus tiempos de producción que invierten en el trabajo de su día a día.

¿En qué otros escenarios se mantendría?
Mientras el software este desarrollado con altos estándares y siga resolviendo los problemas de la empresa este será escalable y tolerante a cambios lo cual evitara deudas técnicas que repercuten en costos futuros. además este tipo de software son adaptables para diferentes industrias.

Sistema: Gestion de compra de cadena de electrodomesticos
problema que resuelve:
.agiliza y simplifica el proceso de compra
.evita la impresion en papel de facturas y lo manda a un email
RNF: ver los pedidos en tiempo real
. tener un conteo de stock actualizado
. al enviar las facturas guardarlas en una base de datos

¿como cambiaria su arquitectura?
hacer una version web del mismo, e implementando el almacenamiento de los datos en la nube

¿En qué otro escenario debería repensarse completamente?
en el caso de que se vea un potencial ataque que impliquen la perdida de datos sensibles

¿En qué otros escenarios se mantendría?
al cambiar de tecnologia en la que esta basada

Sistema: Aplicativo para de turismo para dar contexto histórico de Medellin
Problema que resuelve:
Incentivarse a las personas a conocer mas afondo ala historia de medellin aparte de la guerra, el narcotrafico y la explotación sexual; ser mas consientes de como fue construido y que hay detrás de cada lugar sin darle tanto enfoque a los temas anteriores.

También ofrecer la ubicación de los lugares históricos y dar alternativas de estas rutas sin necesidad de guías

Requerimientos no funcionales:

• tener un listados de los lugares históricos y la infomacion de estos

• Mostrar la ubicación de los lugares dependiendo la ubicación del usuarios

• tener conexión a Internet y gps

• Mostrar los lugares agregados en tiempo real

producto reutilizable

¿Cómo cambiaría su arquitectura?

crear el aplicativo como híbrido para que este pueda ser utilizado en varios sistemas mobiles y con una arquitectura atomica y tener la reutilizacion de componentes para aplicativos futuros

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

Se debe repensar en el manejo de una aplicación web, ya que el diseño y planeacion de esta se creo para aplicaciones mobiles

¿En qué otros escenarios se mantendría?

Se mantendría toda la recopilación de datos históricos y el manejo de estos en las bd de mongo y el manejo de firebase para las actualizaciones de los datos en tiempo real