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

13/24

Lectura

El reto que tienes es tomar un sistema conocido (del trabajo, algún proyecto propio o un sistema que hayas usado del que conozcas su arquitectura).

...

Regístrate o inicia sesión para leer el resto del contenido.

Aportes 524

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

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

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

RNF:

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

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

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

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

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

¿En qué otros escenarios se mantendría?

  • Utilizando otra DB como PostgreSQL.

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

1.- ¿Qué problemas resuelve?

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

2.- Requerimientos no funcionales

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

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

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

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

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

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

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

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

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

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

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

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

Sistema de corresponsal para transacciones bancarias
Problemas que resuelve.

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

Requerimientos no funcionales.

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

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

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

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

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

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

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

  • Su acceso gratuito.

  • Su sistema multi-idioma.

Cambio de arquitectura

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

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

Sistema para control de calidad de cacao

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

Requerimientos no funcionales:

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

Como cambiaría su arquitectura:

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

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

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

¿En qué otros escenarios se mantendría?

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

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

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

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

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

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

¿En qué otros escenarios se mantendría?

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

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

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

Requerimientos
Asegurar el ingreso de los usuarios al sistema.

¿Cómo cambiaría su arquitectura?

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

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

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

Sistema de Gestión de Riesgos
Problemas que resuelve:

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

RNF:

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

Para hacerlo un producto reutilizable:

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

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

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

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

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

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

Arquitectura

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

Escensarios a repensar

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

Uber

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

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

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

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

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

sistema conocido
Sistema de acceso a personas a empresa

Describir qué problemas resuelve

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

cuáles son sus requerimientos no funcionales.

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

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

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

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

¿En qué otros escenarios se mantendría?

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

Sistema de control de salud y personal:

  • Problema a resolver: tener control de ingresos y egresos del personal y seguimiento de sus consultas medicas.
  • Requerimientos no funcionales:
    • Mostrar información en tiempo real.
    • Diseño intuitivo.
  • Se debería de repensar totalmente si cambiaran el método de ingreso actual de personas y se mantendría si se sigue usando el mismo método.

Sistema de cita para veterinarios:

Que problema resuelve:

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

Requerimientos no funcionales:

Almacenar la información del cliente.

Almacenar la información de la mascota.

Guardar el día y hora agendado.

Llevar un control de las vacunas ya puestas.

Que cambiaría

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

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

Sistema de ventas por redes sociales

  • Problema que resuelve:
    Encontrar el mejor producto o servicio lo más rápido posible y en un solo lugar.
    Requerimientos no funcionales:
  1. seguridad en los pagos y cobros.
  2. seguridad en el manejo de la información.
  3. veracidad y calidad de los servicios y productos ofrecidos
  4. rapidez en contestar a preguntas de usuarios

Producto Reutilizable:

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

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

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

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



Sistema:

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

Que problema resuelve?

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

RNF:

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

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

¿Cómo cambiaría su arquitectura?

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

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

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

¿En qué otros escenarios se mantendría?

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

Chatbot asesoría financiera.

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

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

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

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

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

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

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

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

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

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

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

  1. Problema que resuelve: Afiliación, reafiliación, reingreso y retiro de trabajadores a empresas.
    RNF:
  • El sistema debe permitir la afiliación, reafiliación, reingreso y retiro del trabajador en tiempo real.
    -El sistema debe permitir conexiones simultáneas
    -El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario final.
    -El sistema debe ser capaz de procesar 10000 solicitudes por segundo.
  1. ¿Cómo cambiaría su arquitectura en caso de que sea un producto reutilizable?
    La plataforma es parametrizable de manera que otra compañía la podría adaptar según su necesidad.
  2. ¿En qué otro escenario debería repensarse completamente?
    Si se quiere evolucionar a una aplicación móvil.
  3. ¿En qué otro escenario se mantendría?
    Migrar de on-premise a la nube

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

Requerimientos no funcionales:

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

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

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

¿En qué otros escenarios se mantendría?

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

Dispositivo de Monitorización de Transformadores

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

sistema
Automatización de procesos documentales
problemas

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

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

Requerimientos no funcionales:

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

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

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

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

¿En qué otros escenarios se mantendría?

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

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

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

Servidor Web Socket para domotica

  • Problemas que resuelve:
  1. Envío y recepción de cadenas de instrucción encriptadas.
  2. Actualización de estado en una base de datos, usando las cadenas para saber el identificador del dispositivo a actualizar
  • Requerimientos no funcionales:
  1. Comunicación de acciones tomadas en la interfaz de usuario (prender apagar una lampara, motores, etc) hacia tarjeta electrónica central
  2. Ejecución de instrucciones en cadena (escenarios) a determinada hora sin intervención del usuario.
  3. Ejecución de instrucciones en cadena (escenarios) si se detecta la activación de uno o más sensores de movimiento pero solo cuando la luz natural después del anochecer y antes del amanecer
  • ¿Cómo cambiaría su arquitectura?
    Se removerían los requerimientos no funcionales que el usuario no dispusiera.
  • ¿En qué otro escenario debería repensarse completamente?
    En el caso de que la tarjeta electrónica central elegida no pueda realizar una conexión hacia un servidor WebSocket

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

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

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

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

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

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

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

Sistema
CRM

Problema que resuelve

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

Requerimientos no funcionales

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

¿Cómo cambiaría su arquitectura?

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

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

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

¿En qué otros escenarios se mantendría?

  • En empresas del mismo giro.

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

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

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

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

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

Herramienta de Creacion y Gestion de Facturas.

¿Que problemas resuelve

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

Requerimientos no funcionales

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

¿Que cambiaria?

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

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

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

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

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

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

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

Se mantendría para cualquier otro colegio

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

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

Riesgos:

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

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

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

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

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

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

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

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

Online Judge

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

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

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

Glovo
Resuelve:

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

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

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

  • Acceso desde cualquier equipo con Microsoft Excel.

  • Información obtenida de documentación impresa.

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

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

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

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

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

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

¿Como cambiaría su arquitectura?

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

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

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

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

  • Acceso seguro al sistema

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

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

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

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

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

¿Cómo cambiaría su arquitectura?

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

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

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

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

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

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

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

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

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

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

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

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

Requerimientos no funcionales

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

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

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

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

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

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

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

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

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

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

Proyecto personal:

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

Los principales problemas que resuelve este sistema son:

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

Requerimientos no funcionales.

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

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

¿Cómo cambiaría su arquitectura?

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

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

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

¿En que otros escenarios se mantendría?

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

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

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

Requerimientos no funcionales:

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

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

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

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

**Sistema:** Pasarela de Pagos en Perú **Problemas que Resuelve:** 1. **Facilitar transacciones electrónicas:** Permite a los comerciantes recibir pagos electrónicos de manera segura y eficiente. 2. **Integración con múltiples métodos de pago:** Soporta tarjetas de crédito, débito, transferencias bancarias y billeteras digitales. 3. **Seguridad:** Asegura que las transacciones sean seguras mediante la implementación de protocolos de seguridad como PCI-DSS. 4. **Procesamiento rápido:** Minimiza el tiempo de espera para la autorización de pagos. 5. **Conformidad regulatoria:** Cumple con las normativas locales e internacionales. **Requerimientos No Funcionales:** 1. **Escalabilidad:** Debe manejar un alto volumen de transacciones sin degradar el rendimiento. 2. **Disponibilidad:** Alta disponibilidad para asegurar que el sistema esté operativo 24/7. 3. **Seguridad:** Cumplimiento con estándares de seguridad como PCI-DSS, cifrado de datos sensibles. 4. **Rendimiento:** Baja latencia en el procesamiento de transacciones. 5. **Fiabilidad:** El sistema debe ser confiable y capaz de manejar fallas de manera eficiente. 6. **Mantenibilidad:** Código bien documentado y modular para facilitar el mantenimiento y las actualizaciones. 7. **Compatibilidad:** Capacidad de integrarse con sistemas de terceros y soportar múltiples plataformas. ###
Sistema de procesos judiciales administrativos Requerimiento Seguir proceso administrativo segú normatividad vigente Seguir proceso judicial administrativo en sus etapas de radicación, reparto, actuaciones y cierre de procesos Escenarios En la nube On promise Híbrido Las anteriores opciones centralizadas o distribuidas o hibrido Riesgos Confidencia de información Cumplimiento de reglas de negocio entre etapas del proceso administrativo y proceso judicial desde la etapa de radicación del proceso hasta el cierre del proceso judicial
Proyecto: Sofware de control y vigilancia de camaras interiores para locales de autoservicio. Problema que resuelve: * Vigilancia del local automatizada * Clasificacion de clientes por comportamiento * Analisis de trafico de personas dentro del local Requerimiento no funcionales * El sofware deberia ser seguro * Tiene que ser facil de usar * El sofware no deberia tener problema de integrarse con diferentes tipos de camara. PARA REUTILIZACION:¿Cómo cambiaría su arquitectura? * Ya es un servicio en la web, asi que podria cambiar el fronted del software para que se adapte a otros tipos de locales de compra. ¿En qué otro escenario debería repensarse completamente? * Deberia repensarse completamente en una feria o una tienda mas informal. ¿En qué otros escenarios se mantendría? * En un supermercado, se mantendria bien.
No la conozco muy bien pero, utilizaría la arquitectura de Moodle está diseñada para proporcionar un entorno flexible y escalable para la entrega de contenido educativo en línea. Su modularidad permite adaptarse a una amplia gama de necesidades educativas y su enfoque en la usabilidad lo hace adecuado para usuarios con diferentes niveles de experiencia técnica. La interfaz de usuario de Moodle proporciona a los usuarios (estudiantes, profesores, administradores) acceso a diferentes áreas y funcionalidades del sistema. Esto incluye el panel de administración, donde los administradores pueden configurar el sitio, así como las interfaces para estudiantes y profesores donde interactúan. Con los cursos y actividades aplicadas al aprendizaje.
Sistema: **Sist. de venta y facturación para retails** Problemas que resuelve: * **Gestión de productos** * **Gestión de stock** * **Facturación fiscal** Req. No Funcionales: * **Seguridad con la información fiscal** * **Buena velocidad de comunicación con el ente fiscal** * **Simplicidad a la hora de realizar las ventas y la facturación** Otros posibles escenarios: * **Útilizar el sistema para diversos países** * **Que no solo haga venta para retail, sino también mayoristas u otro sector comercial** ¿Cómo cambiaría su arquitectura? * **Separando responsabilidades del sistema en microservicios:** * Servicio de facturación * Servicio de stock * Servicio de productos ¿En qué otro escenario debería repensarse completamente? **En el caso de que se quiera útilizar como un facturados más general, incluyendo servicios** ¿En qué otros escenarios se mantendría? **Se mantendría si se conserva el objetivo de ser un sistema de facturación, ventas y control de stock de productos.**
**Sistema:** Sistema de gestión de tickets de soporte informático **Problema que resuelve**: Gestión de tickets de soporte informático para registrar, asignar, dar seguimiento y resolver problemas técnicos reportados por los empleados. **Requisitos no funcionales** Acceso seguro a través de las cuentas del directorio activo. Interfaz intuitiva y fácil de usar para los empleados y técnicos. El sistema debe estar disponible en todo momento. Capacidad para personalizar campos de ticket, flujos de trabajo. **¿Cómo cambiaría su arquitectura?** Se conectaría a una Base de Datos en vez de su conexión actual. Se pensaría en microservicios considerando la escalabilidad. **¿En qué otro necesario debería repensarse completamente?** Cuando la entidad en donde este sistema esté implementada no cuente con licencia de Microsoft 365. **¿En qué otros escenarios se mantendría?** En escenarios donde la entidad cuente con licencias de Office 365, licencia de Power Apps y directorio activo. En empresas pequeñas/medianas donde se requiera una implementación rápida.
**Sistema:** SISTEMA DE GEDTION DE CITAS MEDICAS **Problema que resuelve:** Tener mejor control en la reservación y atención de los pacientes de un centro médico. **RNF:** * Gestionar el registro de los pacientes * Gestionar el registro de las citas * Gestionar el registro de los médicos * El sistema debe permitir gestionar la disponibilidad de las citas * El sistema permitirá el registro del pago de las citas. **Para hacer el sistema un producto reutilizable** **¿Cómo cambiaría su arquitectura?** Haciendo una arquitectura de microservicio para poder agregar más fácil otros modulo. **¿En qué otro escenario debería repensarse completamente?** Si el sistema no tiene una facilidad de escalar fácilmente. **¿En qué otros escenarios se mantendrían?** Si el sistema es fácil de mantener y tiene buena disponibilidad
### Sistema de IA chatbot para hacer preguntas a documentos legales * **Problemas que resuelve** * Dudas sobre documentos legales * Tiempo en comprender de forma general un documento legal * Necesidad de feedback para mayor entendimiento de casos legales * Documentación y almacenamiento de dichas conversaciones * Requerimientos no funcionales * Seguridad: que los datos no se filtren * Privacidad: uso de datos en base a los términos * Capacidad: que logre manejar altas cantidades de datos, usuarios y sesiones * Auditabilidad: que se pueda llevar un registro y analisis de su uso y desempeño * Conformidad: que su resultado tenga utilidad y facilite los procesos en los que se usa * Reutilizable * ¿Cómo cambiaría su arquitectura? * el codigo sería una librería de componentes para crear un chatbot AI de documentos cualquiera * se podrían definir variables como nombres, templates, modelos de OpenAI usados y posibilidad de agregar cofiguraciones * ¿En qué otro escenario debería repensarse completamente? * En el que no se usen documentos de texto, ex. una IA de dibujos a texto * ¿En qué otros escenarios se mantendría? * En dondo el producto tenga conversaciones e iteractue con la información de los documentos.
**Sistema de re-ejecucion de cálculos financieros.** **Contexto :** EL sistema realiza el reinicio de las tablas que registran cálculos sobre operaciones financieras y vuelve a ejecutarlos. Estos dependen de otras tablas que resguardan la información y por ende, realizar la rejecucion de los cálculos supone una limpieza para una fecha especifica. **Problema que resuelve:** Automatización de truncado las tablas de base de datos donde se registran los cálculos. Automatización de la ejecución de calculos nuevamente. Notificación de error y motivo por el cual se ejecuta la app. **Requerimientos no funcionales** Envío en tiempo real de la notificación de ejecución por correo. Guardar registros para auditoría, antes de truncar las tablas. Crear un archivo de Log donde registre cada paso de la ejecución a nivel de código. **¿Cómo cambiaría su arquitectura?** Esta aplicacion se ejecuta en escritorio y es invocada a travez de un script. Su ejecucion esta limitada a un equipo de trabajo de un operador. lo cual implica que esta estacion de trabajo tenga acceso a la base de datos directamente. Por ello podria realizarse una aplicacion web que: \* se ejecute en un servidor que permita acceder desde un navegador web. \* Tendra acceso desde ese servidor a las base de datos requeridas. \* Permita seleccionar el esquema, tabla y datos de conexion a la base de datos. \* Permita seleccionar las fechas desde un combo. \* Muestre en tiempo real los pasos ejecutados y si existe algun inconveniente en alguno de ellos. \* Genere un reporte de los registros identificados para ser eliminados y pueda ser descargado por la persona que invoca el app. \* Registre los datos de ubicacion y fisicos del equipo desde donde se esta ejecutando y guarde el historial de lo realizado. **¿En qué otro escenario debería repensarse completamente?** Las diferentes tecnologias que podrian usarse para el desarrollo de la app web. Verificar la razon por la que se requiere re ejecutar y realizar un analisis completo del problema para validar si la solucion es la mas optima. **¿En qué otros escenarios se mantendría?** la conexion a esquemas de base de datos de diferentes fuentes y tipos. ejecucion de las sentencias hacia las tablas no esta asociada a una estructura especifica por lo que puede realizarse a cualquier esquema de BD. al ser una app web/escritorio podria configurarse para ser multiplataforma.
Hola yo entendi el problema asi, aunque creo que con unos diagramas de requerimientos hubiera estado mejor ![](https://static.platzi.com/media/user_upload/image-14d4212a-e963-4cd0-9ab5-3aaa0f0d713b.jpg)![](https://static.platzi.com/media/user_upload/image-048cb802-e172-4b8e-82f5-26b95d598afc.jpg)![](https://static.platzi.com/media/user_upload/image-df7f1ba9-046f-41db-bf35-60ff1b71b251.jpg)![](https://static.platzi.com/media/user_upload/image-060413ac-32b1-4bab-abf7-7e1435e8aac1.jpg) no entiendo por que se mira asi \*Recomendacion, para tus notas usa onenote, es muy versatil, y tiene un buen de funciones
Proyecto: Portal de Pagos - Resuelve: Plataforma tecnológica que permite hacer pagos programados segun peticiones de manera automática. Requerimientos no funcionales: Portal administrativo expone servicios de integraciones para recepciones solicitudes de ordenes de pago. 1\. Cambios en la arquitectura: \- Implementar una arquitectura de microservicios. Esto permitiría desacoplar las diferentes funcionalidades del sistema y facilitaría la integración con otros servicios externos. Además, se podría emplear una arquitectura basada en APIs RESTful para la comunicación entre los diferentes componentes, lo que proporcionaría una mayor flexibilidad y escalabilidad. 2\. Escenario para repensar completamente: \- Si se necesitara agregar una funcionalidad de procesamiento en tiempo real para detectar y manejar transacciones fraudulentas, sería necesario repensar completamente la arquitectura. En este caso es de considerar una arquitectura basada en eventos, como la arquitectura de streaming de eventos, para procesar grandes volúmenes de datos en tiempo real y tomar decisiones rápidas. 3\. Escenarios donde se mantendría: \- Se mantendría la arquitectura para el procesamiento de pagos programados según solicitudes de manera automática. Si esta parte del sistema ya está funcionando correctamente y no se requiere ningún cambio significativo en los requisitos, no sería necesario repensar completamente la arquitectura para esta funcionalidad. En su lugar, se podrían realizar mejoras incrementales para optimizar el rendimiento y la eficiencia del sistema.
Sistema para la medición inteligente de los servicios públicos que resuelve: con dispositivos IoT recolecta información de los medidores de agua, gas y luz **requerimientos funcionales:** -visualización de los datos del medidor de manera individual -toma de lecturas masivas de todos los medidores -cierre y apertura del medidor -alertas -almacenamiento de datos **no funcionales:** pasarela de pago del servicio seguridad compatibilidad **Escenarios que requieren Repensar la Arquitectura:** Integración con Nuevas Tecnologías Cambio en los Requisitos de Negocio **Escenarios donde la Arquitectura se Mantiene:** Estabilidad en los Requisitos Escalabilidad y Flexibilidad Integradas
Proyecto: "Sistema de gestión de auto-evaluaciones de docentes para una universidad" 1-¿Qué problemas resuelve? El sistemas mejora la eficiencia al momento de realizar las autoevaluaciones de los docentes para una universidad Al igual ayuda a mejorar el seguimiento de las labores de estos mismos docentes. 2-Requerimientos No Funcionales -Los usuarios deben ser capaces de autenticarse además de solo poder ver las vistas desempeñadas para su rol -El sistema debe tener en cuenta los establecido en una resolución de la universidad para establecer los roles 3-Cómo cambiar su arquitectura El sistema está pensado como una aplicación web, en el cual fue usado una arquitectura mvc, fue programada igualmente usando java con spring boot lo cual lo hace muy escalable, lo único que cambiaría sería su base de datos ya que al ser un prototipo usamos una no muy potente la cual fue mysqlite. 4-En qué otros escenarios se debería repensar completamente En cada universidad o negocio el cual sus reglas no sean parecidos a los acuerdos de la universidad en la que fue basado el sistemas ya que esta aplicación está muy arraigada a las reglas de negocio, además de un sistemas que no solo se quisiera usar en una aplicación web,si no en distintos dispositivos. 5-En qué otros escenarios se mantendrá En universidad las cuales tenían tanto reglas de negocio parecidas, además de que las necesidades sean sólo accesibles a través de la web.
Proyecto: Sistema automático para la gestión de recursos hídricos destinados a generación de energía. **Problema que resuelve:** * Asignar de forma semi-automatica las cuotas de agua y las políticas de regulación en embalses de acuerdo a la disponibilidad hídrica observada y las proyecciones efectuadas a partir de pronósticos hidrometeorologicos. **Requerimientos Funcionales:** * El sistema debe validar la disponibilidad de las observaciones adquirida a través de las redes de monitorio. * El sistema debe verificar la calidad de los datos obtenidos. * El sistema debe validar la disponibilidad de datos de pronostico. * El sistema debe validar que las proyecciones y políticas se ajusten a restricciones físicas y normativas existentes. **¿Cómo cambiaría su arquitectura?** * Posibilidad de modificar los atributos vinculados a las cuencas hidrograficas mediante la implementación de una geodatabase. **¿En qué otro escenario debería repensarse completamente?** * El producto se debería repensar si el recurso hídrico sera utilizado para otras labores, como consumo humano o regadío. **¿En qué otros escenarios se mantendría?** * Podría conservarse para el abastecimiento de otros procesos industriales.
**Reto: Clasificación de requerimientos y análisis de riesgos** **Arquitectura de UBER** **En este escenario estoy interesado en aplicaciones APP de transporte publico** **El reto que tienes es tomar un sistema conocido (del trabajo, algún proyecto propio o un sistema que hayas usado del que conozcas su arquitectura).** **Arquitectura de UBER** Un usuario puede solicitar un viaje a través de la aplicación y, en unos minutos, un conductor llega cerca de su ubicación para llevarlo a su destino. Anteriormente, Uber se construyó sobre el modelo de arquitectura de software » monolítico. Tenían un servicio de backend, un servicio de frontend y una sola base de datos. Usaron Python y sus marcos y SQLAlchemy como la capa ORM para la base de datos. Esta arquitectura estaba bien para una pequeña cantidad de viajes en algunas ciudades, pero cuando el servicio comenzó a expandirse en otras ciudades, el equipo de Uber comenzó a enfrentar el problema con la aplicación. Después del año 2014, el equipo de Uber decidió cambiar a la » arquitectura orientada al servicio » y ahora Uber también maneja la entrega de alimentos y la carga. **Describir qué problemas resuelve y cuáles son sus requerimientos no funcionales.** Seguimiento de las API de HTTP Administrar perfil Recopile comentarios y calificaciones Promoción y cupones, etc. Detección de fraude Fraude de pago Abuso de incentivos por parte del conductor Cuentas comprometidas por hackers. Uber utiliza datos históricos del cliente y alguna técnica de aprendizaje automático para abordar este problema. Si tuvieras que hacer de este sistema un “producto reutilizable” en otros escenarios: **¿Cómo cambiaría su arquitectura?** Cambiar por números de sillas disponibles por ciudades. **¿En qué otro escenario debería repensarse completamente?** A nivel nacional Uber entre ciudades ¿En qué otros escenarios se mantendría? En servicios de camiones
Sistema: Sistema de gestión de turnos de un centro de atención médico Problemas que resuelve: * Identifica los usuarios a través de su documento de identidad * Clasifica a los usuarios dependiendo de la razón de la visita * Ordena a los usuarios por orden de llegada y prioridad o urgencia * Asigna un profesional especializado para la necesidad de cada cliente. Requerimientos no funcionales * Mantener los datos del cliente confidenciales * Asegurar y encriptar datos del paciente El producto se podría reutilizar en una toma de turno para un banco en donde hay que prestar atención al tipo de cliente y de tarjeta que tenga para la atención prioritaria. Si se repiensa para un sistema de turnos en una carnicería en donde no es necesario conocer al usuario ni lo que que quiere, simplemente ordenarlo por orden de llegada.
### 1. ¿Cómo Cambiaría su Arquitectura? Para hacer el sistema de reservas de hotel más reutilizable, se podrían realizar los siguientes cambios en su arquitectura: * **Modularización**: Rediseñar el sistema en módulos independientes y bien definidos. Por ejemplo, separar la gestión de reservas, el manejo de usuarios, y la integración de pagos en módulos independientes que puedan ser fácilmente reutilizados o reemplazados según sea necesario. * **APIs Genéricas y Personalizables**: Desarrollar APIs que permitan una mayor flexibilidad en la integración con diferentes tipos de servicios y plataformas. Por ejemplo, una API de reservas que pueda ser utilizada tanto para hoteles como para reservas de vuelos o alquiler de vehículos. * **Configurabilidad y Personalización**: Permitir que aspectos clave del sistema, como la interfaz de usuario, flujos de trabajo y lógica de negocio, sean altamente configurables para adaptarse a diferentes necesidades. ### 2. ¿En Qué Otro Escenario Debería Repensarse Completamente? Un escenario donde el sistema debería repensarse completamente sería en el contexto de la reserva y gestión de eventos a gran escala, como conferencias o conciertos. Este tipo de eventos requiere una logística y características muy diferentes a las de las reservas hoteleras, como la gestión de asientos, venta de entradas, control de acceso, coordinación con múltiples proveedores y una mayor énfasis en la gestión de la experiencia del cliente antes, durante y después del evento. ### 3. ¿En Qué Otros Escenarios se Mantendría? El sistema podría mantenerse relativamente similar en escenarios que comparten características comunes con las reservas de hotel, tales como: * **Reservas de Alojamientos Alternativos**: Como apartamentos de vacaciones, casas rurales, etc. * **Sistemas de Reservas para Pequeñas Empresas**: Como spas, salones de belleza o restaurantes, donde se requiere gestionar citas y reservas. * **Alquiler de Vehículos**: Donde los usuarios necesitan buscar, comparar y reservar vehículos, similar a la búsqueda y reserva de habitaciones de hotel. En estos escenarios, la estructura básica del sistema de reservas de hotel sería aplicable, con algunas adaptaciones específicas para cada tipo de servicio.
**Sistema de Reservas de Hotel Online** Este es un sistema común que mucha gente ha utilizado, ya sea para reservar habitaciones de hotel, apartamentos de vacaciones, o alojamientos similares. La arquitectura de este tipo de sistemas suele ser compleja, con múltiples componentes interactuando entre sí. ### Descripción General del Sistema 1. **Frontend Web/Móvil**: Interfaz de usuario para que los clientes busquen y reserven alojamientos. 2. **Backend/APIs**: Servidores y lógica de negocio para procesar las búsquedas, reservas, pagos, etc. 3. **Base de Datos**: Almacena información sobre usuarios, hoteles, reservas, tarifas, etc. 4. **Sistema de Gestión de Contenido (CMS)**: Para que los proveedores de alojamiento gestionen sus listados, disponibilidad, precios, etc. 5. **Integración de Terceros**: Conectarse con sistemas de pago, análisis de datos, servicios de marketing, etc. 6. **Servicios de Seguridad y Autenticación**: Garantizar la seguridad de los datos del usuario y las transacciones. 7. **Infraestructura de Cloud y Escalabilidad**: Para manejar fluctuaciones en la demanda y almacenamiento de datos. ### Problemas que Resuelve y Requerimientos No Funcionales 1. **Búsqueda Eficiente y Reservas**: Permite a los usuarios buscar y reservar alojamientos de forma rápida y sencilla. 2. **Manejo de Grandes Volúmenes de Datos**: Debe ser capaz de manejar un gran número de listados y reservas simultáneamente. 3. **Seguridad y Privacidad**: Proteger la información personal y financiera de los usuarios. 4. **Alta Disponibilidad y Escalabilidad**: Debe estar disponible en todo momento y escalar según la demanda. 5. **Interoperabilidad**: Integrarse con diversos sistemas de pago, CRM, y otros servicios de terceros.
La universidad a la que asistí tiene un sistema donde los alumnos pueden ver su información sobre el semestre que están cursando, las materias que llevan en cada semestre, sus calificaciones, y pueden reinscribirse cada nuevo ciclo escolar. Un requerimiento no funcional sería el incrementar la seguridad. Ya que cada alumno usa un pin de 4 dígitos como contraseña y este sería muy fácil de adivinar con un ataque de fuerza bruta. Otro sería que si estamos logeados, podemos ver la información de otros alumnos de una forma muy específica y debemos eliminar un campo de la UI o modificar el SQL query para evitar esto. El sistema está hecho con PHP y creo que podría ser actualizado a usar node con typescript o bien NestJS. La UI también debe mejorar pues no es responsiva, quizás con Tailwind y Vue se solucionaría esto.
Sistema: Sitio web de anime (Ej: Crunchyroll) Problemas que resuelve: \- Accesibilidad para aquellas personas que no cuenten con un servicio de streaming de anime con gran variedad de titulos. \- Conectividad para todos los fanáticos del anime que quieran interactuar sobre sus series favoritas, mediante secciones de comentarios. \- Calidad y legalidad a la hora de transmitir los diferentes programas. \- Recomendaciones de otras series basadas en los gustos de un usuario, ayudando a que encuentre nuevas series basados en sus gustos. Requerimientos no funcionales: \- Los capítulos deberán tener calidad igual o superior a 720p y estar subtitulados en diferentes idiomas. \- El sitio web deberá poder avisar todos los días la emisión de los nuevos capítulos de las diferentes productoras de anime a cada uno de los usuarios registrados en la página. \- El sistema deberá tener una opción de estreno de capítulos a tiempo real. \- Los usuarios no registrados podrán acceder al contenido pero no podrán comentar ni recibir contenido personalizado. La reusabilidad de este sistema quedaría bien para otro tipo de sitios muy parecidos, como netflix o youtube. Sin embargo, si existen cambios que podrían considerarse a la hora de implementarlo en una arquitectura similar a los sitios anteriormente comentados. 1\. ![](https://static.platzi.com/media/user_upload/image-8fee705e-fe08-4d23-8570-6a46f2404a34.jpg) En un principio, pensaría diseñar una arquitectura muy pequeña encargada de comunicar un backend hecho en fastAPI con la base de datos donde se alojan toda la información de capitulos y la integración de diferentes microservicios necesarios para la página. Un front utilizando django no por nada más que hace buena sinergia con fastAPI ya que ambos son python. Sin embargo, para sitios como youtube, se tendrían que cambiar muchas cosas para hacerlo más robusto, empezando por un backend mejor en java con springboot, y un front en react, o incluso una arquitectura en la nube que integre mejor los eventos personalizados y ajustados a una hora en específico con lambdas.
Sistema: Sistema KPI Equipos de Alto Rendimiento Problema que resuelve: Resolver de forma estructurada la medición y evaluación del rendimiento de los equipo de desarrollo de software. Requerimientos No Funcionales: 1. Garantizar tiempos de respuesta rápidos para acceder a métricas y visualizaciones de KPIs 2. Asegurar que el sistema pueda manejar un número creciente de equipos sin comprometer el rendimiento. 3. Implementar medidas sólidas de control de acceso para garantizar que solo personas autorizadas puedan acceder a información sensible de los equipos ¿Cómo cambiaría su arquitectura? Cambiaria su arquitectura monolítica a microservicios en python con FastAPI para dividir en servicios pequeños e independientes. ¿En qué otro escenario debería repensarse completamente? La determinación de la alta disponibilidad en el sistema lo cual dependerá de factores como su nivel de transaccionalidad y volumetría. ¿En qué otros escenarios se mantendría? La evaluación del costo-beneficio es crucial, especialmente en casos de muy alta transaccionalidad, donde la migración podría justificarse. Sin embargo, en situaciones de baja transaccionalidad, la migración podría resultar en un gasto innecesario para el cliente.

Sistema de Gestión de Centro de Salud:

  • Problema que resuelve:
    1. Gestión de solicitudes de atención a trabajadores de clientes.
    2. Facilidad de generación de certificados médicos.
    3. Control de historias clínicas y registro de cada paciente.
    4. Gestión de lls servicios prestados y control de gastos en operación e insumos.
  • Requerimientos No Funcionales:
    1. Una fácil operación y control de procesos en tiempo real.
    2. Facilidad en la generación de solicitudes.
    3. Historial detallado de cada persona.
  • Producto re-utilizable, ¿Como cambiaría su arquitectura?:
    1. La App ya está estructurada para funcionar en Web y conectada a APIs.
    2. Implementar PWA.
      -¿En que otro escenario debería repensarse completamente?:
    3. En el caso de que se quiera controlar muchísimos usuarios desde una misma empresa.

Sistema de gestiòn hospitalario
Este sistema permite que los pacientes que acuden por una atenciòn de amergencia puedan contar con una ficha de atenciòn para luego ser completada por los profesionales de la salud que brindan la atenciòn.
Esto evita la duplicidad de datos ya que por cada ficha que se genera se emite un numero de hisoria clìnica para cada paciente.
Requerimientos no funcionales:

  • El sistema deberia interoperar con otros sistemas que cuentan con informaciòn de aseguramiento o acreditaciòn del paciente.

  • La Firma digital digital en las historias clìnicas a travès de un token

  • La receta electrònica para la prescripciòn de los medicamentos

Como cambiaria su arqueitectura?
En la actualidad este sistema esta desarrollado en un ambiente cliente servidor, a la vez se han desarrollado algunas aplicaciones web que consumen los datos de la BASE DE DATOS, la propuesta serìa diseñar una aplicaciòn web, basada en microservicios, ya que muchos de los datos de los pacientes se encuentran en otros sistemas internos y externos de la instituciòn.

En que otro escenario deberia repensarse completamente:
Deberia replantearse en diseñar una nueva soluciòn migrando toda la data actual a la nueva aplicaciòn web, tomando en cuenta todos los nuevos requerimientos que se necesitan.

En que otros escenarios se mantendria:
Serìa dificil que se pueda mantener ya que la instituciòn no cuenta con los còdigos fuente

Sistema de conciliacion de glosas

Permite que los prestadores de servicios de la EPS
gestionen directamente la solictud de cobro
de glosas.

Requerimientos no funcionales

  • Logueo con seguridad
  • Presentar informacion a cobrar en formato excel
  • Presentar documentacion en formato PDF
  • Enviar al prestador via email una notificacion en formato PDF del proceso de recepcion

¿Cómo cambiaría su arquitectura?.. en el momento no la cambiaria, al contrario la forteleceria
para que aplique no solo para EPS si no para otros negocios.

¿En qué otro escenario debería repensarse completamente?.. Creo que el objetivo de la solucion
es la apropiada para el manejo de glosas de lo diferentes core que se tiene en la compañia y no debe salirse de su enfoque.

¿En qué otros escenarios se mantendría?.. Actualmente solo se enfoca en EPS, y la idea es que SOAT, POLIZA y otros negocios que manejen glosas entren a operar por este componente y cambio seria simple con un parametro que se maneje desde el front y componente central sepa donde redirigir los servicios de solictidud o de gestion de la informacion

Proyecto de realidad aumentada con georreferenciacion en unidades administrativas de una facultad
Problematica: Es que las personas que pasan por primera vez a esa facultad tienden a demorar mucho tiempo el encuentro de la ubicacion exacta de alguna unidad administrativa como carreras, direccion facultativo, entre otros.
Solucion problema: Se resolvera usando una aplicacion web con realidad aumentada de manera interactiva donde podran los usuarios visualizar una objeto 3D, que hace referencia a esa unidad administrativa deseada.
Requerimientos funcionales:
-La aplicacion almacena usuarios.
-Los usuarios deben elegir alguna unidad administrativa deseada y ahi aplicar el uso de la realidad aumentada con geolocalizacion.
-La aplicación debe renderizar un modelo 3D en la unidad administrativa deseada para que el usuario pueda encontrarlo.
-Los usuarios deben calificar a través de estrellitas y si quieren dejar algún comentario para posibles mejorar de la aplicación.
Requerimiento no funcionales:
-La aplicación deber tener una arquitectura backend y frontend para la eleccion de herramientas para el desarrollo.

Si tuvieras que hacer de este sistema un “producto reutilizable” en otros escenarios:
otro escenario: Una guia con realidad aumentada para museo de iglesias para x departamento
¿Cómo cambiaría su arquitectura?
Seria un depende porque este proyecto seria un aporte para dar a conocer las iglesias de cierta region pero si ya alguna iglesia esta interesada en invertir en este proyecto, se podria crear mas roles por ejm (administrador, usuario, empleados, …)

¿En qué otro escenario debería repensarse completamente?
otro proyecto: realidad aumentada para dar conocimiento en libros :caso el cuerpo humano.
En este caso a que repensarlo porque ya existen otras manera del uso de esta tecnología con realidad aumentada. tambien ya tendríamos que revisar cierto libro y ver las secciones donde sean necesarias la muestra o renderización del modelo 3D creado( cabeza, pierna, codo, ….)
¿En qué otros escenarios se mantendría?
En el anterior proyecto de iglesias, ahi si se mantendrá una gran parte porque tambien es una orientación interactiva con geolocalización y usando la realidad aumentada.

Anexos: cuando digo georreferenciación me refiero a que tomare las coordenadas con google maps(latitud, longitud), en este caso de las unidades administrativas.
Y cuando menciono geolocalización me refiero a las coordenadas(latitud,longitud) del dispositivo móvil en tiempo real.

**Integración de envíos** El sistema permite integrar una plataforma ecommerce a nuestra plataforma consumiendo varios endpoints y webhooks para la obtención de informacion relacionada a nuevos envíos *Requerimientos no funcionales:* Transformar la información que nos proporciona el ecommerce al formato de nuestra plataforma. Actualmente el código de la integración solo se encuentra en un solo archivo, seria mas eficiente aplicar la arquitectura Clean Code en la integracion.

Sistema: Sistema de alertas en ambientes médicos
Problema que resuelve:

  • Generar una atención inmediata al paciente
  • Guardar series temporales de la evolución de un paciete.
    Riesgos no funcionales:
  • Tiempo real.
  • Debe guardar data historica de pacientes.
  • Consecuente con temas regulatorio de datos.
  • Alta disponibilidad.
    Producto reutilizable:
  • Generar un producto basado en la nube. Donde el Software no dependa de altos recursos de maquina.
    ¿Cómo cambiaría su arquitectura?
  • Software local a software online.
    ¿En qué otro escenario debería repensarse completamente?
  • Pandemias o desastres naturales, donde los pacientes pueden ser externos al centro de atención.
    ¿En qué otros escenarios se mantendría?
  • Centros de atención a nivel nacional.

Sistema de ventas e inventario para una tienda de ropa.
Problema que resuelve:

  • Facilitar la gestión de inventario, entrada y salida de productos.
  • Control de inventario a través del kardex del mismo.
  • Gestión de reportes de ventas por producto y vendedor en un determinado rango de fechas.
  • Gestión de clientes.
  • Gestión de créditos.
  • Gestión de pago.
  • Gestión de proveedores.

Requerimientos No funcionales:

  • Autenticación federada.
    ¿Cómo cambiaría su arquitectura?(Si se llegara a vender en otros países)
  • Se optaría por tener microservicios por funcionalidad.
  • Se dejaría todo parametrizable, incluyendo la moneda conque se está vendiendo y también con la que se está comprando, teniendo en cuenta la tasa de cambio en dicho momento.
    _
    ¿En qué otro escenario debería repensarse completamente?_
  • Si la tienda abre sucursales en muchos países y su normatividad en facturación sea incompatible.

¿En qué otros escenarios se mantendría?
Si la normatividad de facturación es compatible.

Proyecto

Sistema de gestión de pacientes.

¿Qué problema resuelve?

Evita la duplicidad de expedientes y otorga visibilidad a estos de forma granulada y limitada a los diferentes usuarios del sistema y gestiona citas con especialistas u otros involucrados.

Requerimientos no funcionales

  • Como usuario registrado del sistema, debo ser capaz de acceder a la información del paciente que mi rol necesita.
  • Como usuario registrado del sistema, debo ser capaz de actualizar exitosamente la información de un paciente que mi rol puede modificar.
  • Como usuario registrado del sistema, puedo dar de alta pacientes sin duplicar registros de forma exitosa.
  • Como usuario registrado del sistema, puedo iniciar sesión de forma segura.
  • Como usuario registrado del sistema, puedo ver el historial actualizado de un paciente cuando lo necesite.
  • Las interfaces deben ser sencillas, presentando fácil acceso a la información del paciente.
  • El sistema debe ser capaz de operar en linea sin interrupciones durante el horario laboral del centro médico.
  • El sistema debe asegurar consistencia y accesibilidad en la información que maneja.
  • El sistema debe ser capaz de ligar las actualizaciones a la información que maneja con los usuarios que las generan.

¿Cómo cambiaría su arquitectura?

  • Modificaría su estructura en base de datos para poder manejar múltiples centros médicos.
  • El sistema de autenticación tendría que reflejar las restricciones de existir multiples centros médicos del sistema.

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

Cuando el sistema requiera almacenar distintos tipos de evaluaciones según las necesidades del centro médico.

¿En qué otros escenarios se mantendría?

Cuando el sistema es utilizado por otros centros médicos de la misma rama de manera aislada.

Esta son mis propuestas para un proyecto personal de renta de carros desarrollado en Java, agradezco cualquier feedback 💚

Sistema: Servicio de Alquiler de Carros Nacional
Problemas que resuelve:

  • Gestiona el proceso de reservación en linea del alquiler de un carro
  • Crea usuarios vinculados con datos relevantes para escoger el carro que se ajusta a las necesidades del cliente
  • Despliega un catálogo de vehículos disponibles para la renta
  • Gestiona la entrega eficiente del vehículo a una hora y lugar conveniente para el cliente
  • Posibilita la aplicación de descuentos especiales al superar una cantidad establecida de días rentados
  • Envío de confirmación y factura electrónica por medio de correo

    Requerimiento No Funcionales
  • Ver la localización del carro que se quiere rentar
  • Guardado en base de datos la información relevante del usuario para personalizar su experiencia en la aplicación
  • Recomendación de carros de nuevo ingreso y más usados
  • Recordatorio de las fechas para devolver el vehículo y agencias para devolverlo

    Para hacer el sistema un producto reutilizable
    ¿Cómo cambiaría su arquitectura?
  • Creando una aplicación móvil para Android y IOS con notificaciones Push
  • Mejorar los tiempo de respuesta implementado CDN cercanos a las areas con mayor número de usuarios
  • Conseguir colaboraciones con marcas establecidas de carros que integren sus servicios con los de la aplicación de alquiler de carros

    ¿En qué otro escenario debería repensarse completamente?
  • Cuando el servicio de alquiler se expanda a otros países con normas e impuestos distintos
  • Si se quiere ofrecer la renta de productos distintos a los vehículos como libros o equipo deportivo

    ¿En qué otros escenarios se mantendría?
  • A la hora de adaptar la aplicación a otro idioma
  • Cuando se migra a otra base de datos o servidores para mejorar el tiempo de respuesta
  • Sistema: Software para SPA rústico con tinajas.
    • Problemas que resuelve
      • Resuelve la toma de horas y disponibilidad de las tinajas o box de masajes para que los clientes sepan en qué horarios hay disponibilidad
      • Resuelve el problema del registro de turnos o jornadas laborales realizados por el equipo del SPA. Registros que luego pueden ser exportados en formato Excel para su análisis.
      • Resuelve la comunicación entre el SPA y los clientes, ya que se envía mails una vez se haya hecho efectiva la reserva, o su modificación de fecha en caso de ser necesario.
    • ¿Cómo cambiaría su arquitectura?
      • Re haciendo toda la web a algo más a la medida, ya que actualmente es un CMS con algunos pluggins o servicios externos que facilitan la toma de horas y otras funciones explicadas anteriormente.
    • ¿En qué otro escenario debería repensarse completamente?
      • En el escenario de querer que todo su sistema fuera completamente Mobile, o querer que todo su CMS se desarrolle a su medida, incluyendo los pluggins que usan.
    • ¿En qué otro escenario se mantendría?
      • En el escenario que no quisieran seguir mejorando su CMS/Web, ya que mucha sobre carga en la web actual hace que se vuelva muy lenta al ingresar.

Sistema de gestion de un conjunto de concesionarios que aportan servicios de mantenimiento a sus vehiculos
Problemas que resuelve:
- El almacenamiento de la informacion de los vehiculos
con sus dueños y que servicio solicitaron
- Proporciona un sistema para procesar pedidos de
servicios de nuevos vehiculos
- Tambien proporciona un sistema de facturacion
funcional para el dia a dia
- El diseño de la aplicacion permite sacar estadisticas
de los diferentes concesionarios tipo “Cuales son los
concecionarios que mas facturan?”

Requerimientos no funcionales:
- El sistema debe de llevar un inventario de los
productos que se utilizan en los servicios y cuales son “Ecologicos”
- El sistema debe llevar una base de datos de clientes
y saber decir si un cliente cuenta con las compras suficientes para considerarse un “cliente frecuente”
- La interfaz del sistema debe tener tematica “Ecologica”

Si tuviera que reutilizar este software por ejemplo para una panaderia ¿Que cambiaria en su arquitectura?

Lo principal que cambiaria es que ya no hay que registrar “varias panaderias” sino solo una entonces el esquema de la base de datos cambiaria en ese aspecto, tambien que ya no ofreceria servicios sino que solo un producto, “pan”.
Se mantendira en llevar la facturacion, el registro de los empleados y clientes, el inventario y estadisticas para intentar tomar mejores decisiones.

Sistema: Envío masivo de información.

Problema que resuelve:

  • Permite enviar 1 comunicado a miles de correos
    electrónicos al tiempo.
  • Gestión de estadísticas de envío y rebotes.

Requerimientos no funcionales:

  • Seguimiento en vivo de los envíos y rebotes.
  • Auto gestión del usuario

¿Como cambiaría su arquitectura?
R. Permitiendo que el diseño a difundir se pueda editar fácilmente. También que se pueda personalizar el mensaje de acuerdo al destinatario.

¿En que otro escenario debería repensarse completamente?
R. No entendí la pregunta 😦

¿En qué otros escenarios se mantendría?
R. En las empresas que promocionan sus servicios o productos a sus clientes para aumentar sus ingresos.

Software de sistema de gestion y registro de productos Market
Los problemas que resuelve son:

  • Administrar ventas de la empresa
  • Ordenar inventario de productos por categoría, marca e id, revisión de inventario, fecha de compra y precio unitario
  • Generar facturación de venta a clientes indicando fecha, vendedor, total de venta, efectivo recibido y devuelto, y lista de los artículos con el precio
  • Procesar productos de compra de los clientes
  • Generar registro y reportes de venta
  • Administrar permisos a empleados, donde solicite una contraseña de acceso para que los empleados puedan interactuar en el sistema
  • Visualizar compra hacia el cliente y el empleado
  • El sistema debe tener una base de datos con los productos registrados
  • Interacción con un lector de códigos de barra que leerá los productos y se podrá visualizar el producto y total de compra

y sus requerimeintos no funcionales son:

  • La modificación en los productos se debe observar por los empleados que acceden al software
  • El software debe funcionar como mínimo con 15 computadoras para cada empleado
  • El administrador y jefe es quien dará permisos y cambios en el software
  • Se debe realizar copias de seguridad de los registros mensualmente
  • Se debe hacer mantenimiento en caso de actualización o nuevos requisitos del software
  • Los empleados deben notificar fallas o problemas con el software
  • Uso máximo por empleado de 8 horas

Sistema de liquidacion de impuestos:

El problema consiste la necesidad de los clientes de ordenar, contablizar y registrar las facturas con su contenido para presentar sus impuestos al estado.

Los requerimientos serian la implementacion de sistemas de usuario para los clientes, notificaciones para el registro de facturas, programacion de los calculos contables, etc.

En caso de ser reutilizable, cambiarian detalles de la arquitectura segun las leyes tributarias de cada pais o de cada cliente, por ejemplo empresas en lugar de personas.

Problemas resueltos por el sistema:

  • Gestión de inventario: el sistema puede realizar un seguimiento de los productos, controlar el stock y facilitar la reposición de existencias.
  • Procesamiento de pedidos: el sistema permite a los usuarios realizar pedidos de productos, calcular precios, gestionar pagos y generar facturas.
  • Gestión de clientes: el sistema almacena información sobre los clientes, como datos de contacto, historial de compras y preferencias, lo que facilita la atención al cliente.
  • Administración de empleados: el sistema puede gestionar los perfiles de los empleados, asignar roles y permisos, y rastrear el desempeño laboral.

Requerimientos no funcionales:

  • Escalabilidad: el sistema debe ser capaz de manejar un alto volumen de datos y usuarios sin degradar su rendimiento.
  • Seguridad: se deben implementar medidas de seguridad para proteger la información confidencial, como datos personales y detalles de pago.
  • Usabilidad: el sistema debe ser intuitivo y fácil de usar para los usuarios finales, con una interfaz clara y funcionalidades accesibles.
  • Mantenibilidad: el sistema debe ser fácil de mantener y actualizar, con código limpio, modularidad y documentación adecuada.

Convertir el sistema en un “producto reutilizable” implica pensar en su arquitectura de manera más genérica y adaptable a diferentes escenarios. Algunos posibles cambios podrían ser:

  • Modularidad: dividir el sistema en módulos independientes y reutilizables, de modo que cada uno pueda ser utilizado de manera independiente o combinado con otros módulos según las necesidades del nuevo escenario.
  • Diseño orientado a servicios (SOA): adoptar una arquitectura basada en servicios, donde cada componente del sistema se convierte en un servicio independiente que se comunica con otros servicios a través de interfaces bien definidas.
  • API y microservicios: exponer funcionalidades y datos a través de API bien definidas y utilizar una arquitectura de microservicios, donde cada funcionalidad específica se encapsula en un servicio independiente y se comunica mediante protocolos ligeros como HTTP.

El sistema debería repensarse completamente en escenarios donde los requisitos funcionales o los flujos de trabajo sean significativamente diferentes. Por ejemplo:

  • Si el sistema se utiliza para la gestión de inventario en un negocio minorista, tendría que repensarse por completo si se desea utilizar para la administración de una biblioteca.
  • Si el sistema está diseñado para la administración de empleados en una empresa, requeriría una repensada completa si se desea utilizar para la gestión de estudiantes en una institución educativa.

Sin embargo, en otros escenarios similares donde los problemas resueltos y los requisitos no funcionales son similares, la arquitectura podría mantenerse con ajustes y configuraciones adecuadas para adaptarse a las necesidades específicas del nuevo entorno. Por ejemplo, si el sistema se utiliza para la gestión de inventario en una tienda de electrónica y se desea utilizar para la gestión de inventario en una tienda de muebles, la arquitectura subyacente podría mantenerse con algunos ajustes en la configuración y personalización de los componentes relacionados con los productos, las categorías de productos y los atributos específicos de los muebles.

En resumen, la arquitectura del sistema se mantendría en escenarios similares donde los problemas resueltos y los requisitos no funcionales se mantengan consistentes. Sin embargo, en escenarios diferentes, especialmente aquellos que involucren cambios significativos en los problemas resueltos o en los flujos de trabajo, sería necesario repensar completamente la arquitectura del sistema para adaptarse a las nuevas necesidades.

Sistema: sistema de gestion de empleados de una empresa:
Problemas que resuleve:

  1. gestion del personal, contratacion, vacaciones, etc
  2. envios de email de mesa de ayuda, autorizaciones, etc

RFN: seguridad, disponibilidad, priorizacion de eventos, eficacia, velocidad de respuesta, performance

  1. la comunicacion de los equipos que trabajan en ellos, ya que es un proyecto inertno modular, donde varios equipos trabajan en modulos del producto software.
  2. un modulo encargado de la finanzas de la empresa
  3. aplicable a otras empresa, sistema de llegadas y salidas

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

Requerimientos no funcionales:

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

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

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

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.