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).

Describir qué problemas resuelve y cuáles son sus requerimientos no funcionales.

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

¿Cómo cambiaría su arquitectura?
¿En qué otro escenario debería repensarse completamente?
¿En qué otros escenarios se mantendría?

compártenos en el sistema de discusiones.

Aportes 410

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

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. 

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.

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

Sistema de 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.

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.

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.

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 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 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: 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.

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.

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 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.

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

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

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.

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
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.

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.

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

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

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.

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.

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.

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.

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

Requerimientos no funcionales

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

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

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

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

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

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

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

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

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

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

Proyecto personal:

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

Los principales problemas que resuelve este sistema son:

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

Requerimientos no funcionales.

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

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

¿Cómo cambiaría su arquitectura?

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

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

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

¿En que otros escenarios se mantendría?

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

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

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

Requerimientos no funcionales:

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

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

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

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

Sistema de Promociones y Cashback.
Resuelve:

- Acceso a información y uso de promociones para usuarios del aplicativo.

Requerimientos no funcionales:

- Alta disponibilidad.
- Seguridad en el manejo de datos sensibles.
- Comunicación con Integración de servicios externos.

Producto reutilizable

  • ¿Cómo cambiaría su arquitectura?
- Este es un microservicio, por lo que fue especificado en cumplir y comunicarse con otros sistemas exclusivos. Por lo tanto su arquitectura podría ser la misma, pero como producto debería de ser más abstracto.
  • ¿En qué otro escenario debería repensarse completamente?
- Dada el planteamiento como producto, debe repensarse si convendría cambiarlo a un modelo de distribución SaaS.

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

- Si el sistema es para un cliente con caracteristicas parecidas a la cual fue pensado.

Plataforma web de asignacion de cargas entre transportistas y operadores logisticos.
Problemas que resuelve:

  • Reclutamiento y capacitación de transportistas con verificación de documentos.

  • Asignación y seguimiento de rutas.

**Requerimientos no funcionales:
**

  • Ubicación en tiempo real
  • Notificacions push para el estatus de las rutas.

¿Como cambiaría su arquitectura para que el sistema fuese reutilizable?

Crearía una aplicación movíl, donde tanto transportistas como operadores logisticos puedan libremente registrarse, los operadores logisitcos podrían agregar las rutas que necesiten y los transportistas postular a esas rutas.
Implementaría un patrón de microservicios en el backend utilizando nodejs como lenguaje en el backend, y una base de datos noSql(MongoDB)

¿En que otro escenario debería repensarse completamente
Solo en caso de que se cambie el alcance del proyecto y ya no sea solo entre transportistas y operadores logisticos.

En que otros escenarios se mantendría

El proyecto es un sistema de administración de clientes cuyo objetivo es tener la trazabilidad de las oportunidades y ventas que se realizan a los diversos clientes;

Requerimientos no funcionales

  • Módulo de seguridad
  • Disponibilidad
  • Funcionalidad
  • Validaciones

¿Cómo cambiaría su arquitectura?
La arquitectura se encuentra basada en una aplicación web donde se procesará y se mostrará toda la información necesaria para la toma de decisiones

¿En qué otro escenario debería repensarse completamente?
si desearamos cambiar la estructura y que ne lugar de ser una aplicación web fuera una aplicación movil

¿En qué otros escenarios se mantendría?
Se mantendría siempre que la estructura pensada soportara los requerimientos funcionales de los clientes

sistema juntas de acción comunal. requerimientos funcionales. login listado de personas según estado (activo, inactivo, preregistrado) toma de asistencia a reuniones semestrales actualización de datos requerimientos no funcionales filtrado de personas por estado estadísticas de asistencia histórico de cambio de estado

Sistema: Sistema de gestión de recaudos para una organización.
Problema que resuelve: Automatiza el recaudo de cartera de una organización ya que no requiere intervención humanada, adicionalmente le permite a los clientes de la organización recaudar en cualquier momento del día.
Requerimientos no Funcionales:

-Seguridad del tratamiento de información

  • Seguridad de la zona de pagos

  • El sistema debe generar los recibos de caja automáticamente una vez se realiza un pago.

¿Cómo cambiaría su arquitectura?
Cambiaría el diseño de interfaces Frontend, la velocidad de respuesta del sistema y la implementación desde el Backend.
**¿En qué otro escenario debería repensarse completamente? **

  • En caso de aplicar su funcionalidad a entidades bancarias.

  • En caso de que una organización maneje protocolos de recaudos especiales.

¿En qué otros escenarios se mantendría?
Se podría integrar con el Ecommerce.

E sistema elegido es un Sistema de Reportería para Call Centers. Los rewquerimientos no funcionales son la alta disponibilidad, la información de tiempo real y la flexibilidad en la estructura de los reportes.

Para ser reutilizable el sistema debe ser altamente parametrizable

Los riesgos asociados mas importantes son la estabilidad den las comunicaciones y la alta carga de las bases de datos.

Otros riesgos menos importantes pero relevantes son la facilidad de comprensión de las métricas que arroja el sistema y su auditabilidad.

Poco pero honesto!

Reto que estamos resolviendo: Plataforma digital para un banco

Describir qué problemas resuelve y cuáles son sus requerimientos no funcionales.

funcioanles

  • Benficios al usuario al tener una sucursal movil.
  • No hacer filas para transacciones
  • Pagos en linea
  • Consulta de saldo

No funcionales

  • Seguridad y practicidad en trasacciones
  • Conocer saldo 24/7
  • Disponibilidad de dinero

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

  • Sistemas de comercio de prodcuto
  • Ventas por catalogo
  • Manejo vitual de cadenas de ahorro
  • App finanzas personales

¿Cómo cambiaría su arquitectura?

  • Cambio a solo usar almacenamiento local
  • No requiere conexion a internet

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

  • Cualquier otro donde no se requiera control de movimientos monetarios

  • Sistemas de inventario

  • Sistemas de navegacion y ubicacion

¿En qué otros escenarios se mantendría?

  • Se mantendria en cualquier esenario donde se requiera transacciones
  • Se mantendria en App que se necesiten control financiero

Sistema de asesoría jurídica online

¿Que problemas resuelve?

  • Facilita el acceso a la asesoría jurídica
  • Reduce costos de asesoría jurídica
  • Permite el acceso a la asesoría júdica desde cualquier parte

Requerimientos no funcionales:

  • Seguridad en que me atienten abogados capacitados.
  • Confiar en que el sistema de turnos/espera para ser atendido es preciso
  • Seguirdad de que la video llamada sea ininterrumpida y sin fallos; de buena calidad.
  • Multiples métodos de pago.
  • Seguridad de la información sensible.

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

¿Cómo cambiaría su arquitectura?
Se peude utilizar en otros escenarios que requieran atención en vívo por medio de video/audio llamadas sin cambiar su arquitectura.
¿En qué otro escenario debería repensarse completamente?
En cualquier escenario diferente al enfoque de atención en línea en tiempo real
¿En qué otros escenarios se mantendría?
En cualquier escenario enfocado en la atención en línea en tiempo real

Describir qué problemas resuelve.
El sistema permite registrar de manera virtual los reclamos que se tiene de los usuarios ya sea de manera virtual, por la página web, y física, de manera presencial.

¿Cuáles son sus requerimientos no funcionales?
Permitir registrar los reclamos de los usuarios, así como brindarle seguimiento y respuesta a su reclamo, también que permita generar tramas para el envió de información a SuSalud

¿Cómo cambiaría su arquitectura?
Actualmente el sistema cuenta con una arquitectura MVC, la cual podría actualizarse aplicando quizá un framework en cual permita añadir mayor seguridad en la validación de usuario, permitir separación entre front y back a fin de trabajar más ordenadamente y seguridad por JWT en las peticiones de los protocolos HTTP.

¿En qué otro escenario debería repensarse completamente?
El sistema debería repensarse si se quiere aplicar a una institución privada fuera del rubro de la salud.

¿En qué otros escenarios se mantendrían?
Si se traslada dentro de instituciones públicas en el rubro de la salud

¿Qué problemas resuelve?
Gestionar ordenes de trabajo a partir de unas tareas que envían las empresas aseguradoras
Requerimientos no funcionales
La aplicación debe estar disponible las 24 x 7.
La aplicación debe ser accesible por distintos roles.
La aplicación debe tener un modulo para gestionar los usuarios.
La aplicación debe ser segura
¿Cómo cambiaria su arquitectura?
Dejaría de ser una aplicación solo para una empresa y se adecuaría para que sea un servicio SaaS. Donde no solo se gestionaría ordenes de trabajo específicas, si no ordenes donde los usuarios puedan seleccionar los campos que necesitan para su orden.
¿En qué otro escenario debería repensarse completamente?
Cuando la arquitectura no esta diseñada para generar ordenes de distintos tipos
¿En qué otros escenarios se mantendría?
Generación de ordenes de trabajo para cualquier empresa

Proyecto: Sistema de administración de guarderías
Resuelve el problema de tener que administrar la información de los alumnos en hojas de papel, permitiendo que se pueda consultar la información en cualquier momento e inclusive generar estadísticas de los alumnos.
Algunos de los requerimientos no funcionales son:

  • Que se protejan los datos sensibles de los alumnos
  • Que se encripte el acceso a la aplicación con SSL
  • Que el padre del alumno y su maestro solamente pueda acceder a la información

Qué resuelve:

  • La compra por parte de amigos y familiares de productos a partir de una lista de nacimiento.

  • La generación de una lista de nacimiento en base a los deseos o necesidades de los padres.

  • La visualización por parte de los padres de los artículos que les han regalado.

Qué no resuelve:

  • La gestión o administración de productos que se incluyen (los coge de un sistema externo).

  • La valoración de los productos comprados.

  • Las devoluciones de los productos comprados.

Requisitos No Funcionales:

  • Permitir la compra de productos de forma segura.

  • Prevenir ataques Man In The Middle.

  • Sincronía entre productos comprados y no comprados para prevenir que dos productos sean comprados a la vez por dos personas diferentes.

En caso de hacerlo reutilizable:
Cómo cambiaría su arquitectura

  • Dividiría el proyecto en dos, separando la lógica del backend (usando un API) y del frontend. Gracias a esto podría escalar mucho mejor mi aplicación, ya que en este caso es una aplicación web y actualmente pretendíamos crear una móvil y nos encontramos con ese problema.

  • Separaría algunos componentes del backend en servicios independientes, como el sistema que se encarga en procesar los pagos, dado que actualmente está fuertemente acoplado al uso que se le da y cuando se le requiere un uso diferente prácticamente es necesario repetir de nuevo el mismo código.

¿En qué otro escenario debería repensarse completamente?
En el caso de que quisiese generalizarse esta aplicación para poder ser utilizada por cualquier tipo de empresa, actualmente la aplicación solo contempla a padres y amigos para una empresa pero no contempla que pudiese haber más de una empresa dando el servicio a sus propios clientes.

¿En qué otros escenarios se mantendría?
En casos donde las ampliaciones del sistema consistiesen en nuevas funcionalidades que complementen las ya existentes, por ejemplo añadir una opción de tíquets de regalo para aquellos amigos/familiares que no sepan que regalo elegir, o les parezcan muy caros algunos y demasiado baratos los otros.

Proyecto: Banca por internet
Problema: El sistema permite a los clientes/usuarios de la banca, realizar operaciones bancarias como pago de sueldos, transferencias bancarias, pago de servicios, entre otros.
RNF:

  • Separar cada capa de negocio en servidores diferentes (front, api, backoffice)

  • Conexión segura vía https y TLSv2

  • El sistema no permite realizar operaciones luego de la hora de cierre contable

Producto reutilizable

  • Junto con el arquitecto y especialista de datos, mejorar la sintaxis de los objetos y querys de la BD ya que todo son vía querys directas en el aplicativo y no por ejemplo con el uso de procedures.

Un sistema de captura de facturas con OCR, usando RPA se capturan los datos de un ERP, se mandan a un servicio de Azure para obtener un texto plano y posterior a ello hacer validaciones individuales.
Requerimientos no funcionales, cumplir SLAs, control documentado de cada factura.
Cambiaría la arquitectura para hacer una busqueda masiva de las facturas (se hace una por una y esto come mucho tiempo). Dejando la busqueda programada a determinada hora y solo enviar a la nube los resultados obtenidos de la busqueda masiva.
Debería replantearse si el tipo de validaciones requieren data de sistemas adicionales.

Sistema de delivery
Problema: Comunicar un cliente y un restaurante, con la entrega a puerta del alimento sin que sea responsabilidad ni del usuario ni del restaurante contactar el repartidor.
No funcionales: Seguridad, Confiabilidad, Rendimiento.
Como cambiaría la arquitectura: La cambiaria de monolito a microservicios, separando cada capa, tanto a nivel de bd como de funcionalidades.
Otro escenarios deberia representarse: Poder atender otro tipo de envios que no sean necesariamente para un restaurante.
Otros escenarios se mantendría: La experiencia para los distintos tipos de usuario debe ser igual sin afectar la funcionabilidad. Tener en consideración los tiempos de despliegue de las aplicaciones.

El proyecto es un modulo de seguridad para motocicletas. (MOSOMOT).
El modulo esta pensado en dar protección a una motocicleta con la finalidad de frustrar un hurto, este modulo se controla por medio de una aplicación Android.
Un requerimiento no funcional de este sistema es seguridad.
¿Cómo cambiaría su arquitectura?
El sistema actualmente lo desarrollo en una arquitectura monolítica, con el tiempo podría cambiar a una arquitectura de capas.
¿En qué otro escenario debería repensarse completamente?
El sistema esta diseñado para motocicletas por lo cual si mas adelante se utilizara en autos tendría que rediseñarse totalmente.
¿En qué otros escenarios se mantendrían?
En motocicletas con sistema de fuel injection.

Desarrollo de Funcionalidad WhatsApp en CallCenter

Problemas que resuelve:
La integración de comunicación vía whatsApp con los clientes de un Call Center donde se pueda establecer una conversación compartir archivos y tener una gestión de esta.

Requerimientos no funcionales:
Performance: Para evitar afectar a las funcionalidades ya existentes
Disponibilidad: mantenerse funcionando durante el tiempo de operación del CallCenter
Seguridad: Encriptar o poner alguna seguridad los archivos compartidos a los asesores telefónicos del Call Center

1.- Como cambiaría su arquitectura?
Probablemente metiéndolo como una funcionalidad más independiente que pueda ser integrada o no al sistema si el cliente lo solicita o necesita.
2.- ¿En qué otro escenario debería repensarse completamente?
Si el proveedor de la integración es el correcto o tener algunas opciones de proveedores de conexión hacia whatsapp
3.- ¿En qué otros escenarios se mantendría?
En la comunicación por otros medios de mensajerías probablemente de otras redes sociales

El priyecto es un sistema de gestion de empleados, para una pequeña empresa, tiene toda las funcionalidades de un CRUD.
Resuelve los problemas, para la gestion de nuevos empleados, bajas, y generacion de contratos laborales mensuales.
Los requerimientos no funcionales de este sistema son, la seguridad, sincronizacion, accesibilidad, confidencialidad.
El sistema actualmente cuenta con una arquitectura por capas, (ONION). Haria un cambio de arquitectura a microservicios.
El siste si puede utilizarse talvez de un otras pequeñas empresas que quieran un sistema propio, sin tener que compartir sus datos a la nube, y utilizar como un sistema on premise.

Sistema Gestor de películas

  • Poder agregar películas
  • Que las películas cuentes con título, trailer, sinópsis y rating
  • Que las películas estén vistas en tarjetas
  • Poder eliminar y editar las películas que se agregan por botones que desplieguen modales

¿ Cómo cambiaría su arquitectura ?
No consideraría cambiar la arquitectura la cual se basa en el modelo MVC

¿En qué otro escenario debería repensarse completamente?
Considero que la forma en la que se encuentra el área de gestión del listado de películas, la posibilidad de relacionar las reseñas junto con un comentario de feedback por parte de quien quiera dar su opinión de la película, que las personas tengan que hacer registro para crear una cuenta desde la cual se les permitirá identificar el comentario

¿ En qué otros escenarios se mantendría ? La integración de las películas al sistema, la bases de datos que se usa

El proyecto es un sistema de producción para restaurantes.
el sistema permite controlar las recetas determinadas por el usuario y controlar los inventarios, costos,merma entre otros.
que cambiaria de este proyecto la forma como afecta las formulas ( recetas ) esto permitiría poder aplicar el sistema en una mayor variedad de empresas de producción.
para esto se deberá incorporar controles de lotes, seriales, entradas y salidas, prioridades de rotación y determinar que no debe ser un sistema amarrado al proceso de facturación.

mi proyecto es una el manejo de una agencia de viajes, que facilita la compra de paquetes y experiencias turísticas.
Los requerimientos no funcionales son: el sistema debe ser escalable para contrarrestar la demanda transaccional , debe ser seguro, debe tener una alta disponibilidad y debe permitir sincronización contantes con sus diferentes integraciones.

Cómo cambiaría su arquitectura = volvería a realizar la definición de la misma ya que actualmente la arquitectura no es funcional.

¿En qué otro escenario debería repensarse completamente? = la arquitectura es monolítica en todos los aspectos de replantearse para pueda ser enfocada a microservicios,

En qué otros escenarios se mantendría: No mantendría nada de lo actual.

El sistema se llama Apolo, es una aplicación web para planeación, seguimiento, y almacenamiento de archivos.

Resuelve el problema de la dificultad presentada al estandarizar procesos y actividades de un grupo de 170 personas laborando en gestión predial, medición de indicadores, y generación automatizada de reportes.

Requisitos de negocio:

  1. La aplicación debe permitir usuarios de planeación que generen planes de trabajo, y usuarios operativos que gestionen las actividades, les den cierre y carguen soporte
  2. La aplicación debe permitir realizar seguimiento a la ejecución de cada actividad y proyecto
  3. La aplicación debe permitir exportar hojas de cálculo estandarizadas para cargar a Power BI
  4. La aplicación debe generar reportes de ejecución de actividades en cada proyecto
  5. La aplicación debe permitir que los usuarios operativos carguen actividades adicionales que no se encontraban dentro de los planes de trabajo

Requisitos de usuario:

  1. La aplicación debe mostrar visualmente las actividades que se tienen que desarrollar para facilitar la priorización
  2. La aplicación debe permitir filtrar las asignaciones por distintos criterios para facilitar el seguimiento

Para hacer del sistema un producto reutilizable

¿Cómo cambiaría su arquitectura?

Cambiando a un sistema modular con una estructura de código más independiente, implementando microservicios, ya que actualmente todo el sistema corresponde a una plataforma única desarrollada en laravel

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

La aplicación está diseñada para proyectos con entregables definidos, donde los productos son documentos elaborados por los trabajadores. Debe repensarse, o generar un módulo adicional, para manejo de materiales y gestión de inventarios en proyectos que así lo requieran.

¿En qué otros escenarios se mantendría?

Todos los escenarios de seguimiento a proyectos cuyos productos / entregables correspondan a información digital.

¿En qué otros escenarios se mantendría?

PROYECTO: Sistema de Gestion de estudio Fotografico
El sitema permite failitar a los usuarios del Estudio el poder ver sus ofertas y precios, y el poder hacer Contratos personalisados de manera remota
RNF: Portabilidad, gestionabilidad y preferencia
-¿Cómo cambiaría su arquitectura?
Arquitectura de microservicios.
-¿En qué otro escenario debería repensarse completamente?
Para empresas que quieran vender habria que repensar y afregar funcionalidades de compras
-¿En qué otros escenarios se mantendría?
Para empresas que quierea promocionar digamos fotos y gestionar una contabilidad de sus finanzas etc.

DiDi

  • Problemas que resuelve
    La facilidad de transportarse en un vehiculo con solo pedir un carro desde la casa utilizando la aplicacion
  • Requerimiento no funcionales
  1. Solicitud de ubicacion
  2. Agilidad de peticion de carro
  3. Diferentes metodos de pago
  4. Costo del viaje antes de la peticion

¿Cómo cambiaría su arquitectura?

Como tal la aplicacion esta muy completa pero en mi caso yo le agregaria la opcion de aquiler de un carro, claro, haciendose reponsable de aquel y con ciertos terminos y condiciones

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

Como tal la app es para telefonos moviles, pero yo le implementaria un lugar en la web en caso que no ocupe un dispositivo movil

¿En qué otros escenarios se mantendría?

Me mantendria en el escenario que es para movil ya que es facil de usar y practico

Sistema de comparacion de valor de polizas de seguro para auto.

Se encarga de ofrecerle al ususario final, una busqueda rapida y efectiva con las principales aseguradoras de su pais, con la opcion de tener minimo 3, maximo 5 opciones de valores de poliza para su mismo auto, tambien permitiendole seleccionar la cantidad de cuotas en la cual pagaria la mencionada poliza. Le permite adquirir y pagar su poliza, todo en la misma plataforma.

Sus requerimientos no funcionales son:

  1. La homologacion de la estructura de datos de cada aseguradora en una misma estructura
  2. La homologacion de valores de poliza de cada aseguradora en un solo formato
  3. Permitir consultar con todas las aseguradoras garantizando la obtención de un resultado
  4. Manejar el balanceo de la carga del sistema para realizar las N cotizaciones de forma asincrona sin afectar el desempeño del sistema y la respuesta visual al usuario final.

¿Como cambiaria su arquitectura?
En la forma de crecimiento de la base de datos, aunque es un minimo porcentaje de creimiento horizontal, trataria de hacerlo lo mas nulo posible, y segun lo que los requerimientos de cada aseguradora me lo permitan, por lo pronto su crecimiento es en un 97% vertical.

¿En que otro escenario deberia repensarse?
En el momento en el que las aseguradoras cambien su forma de consumo de informacion y/o necesiten validacion de seguridad adicionales que impacten otros modulos de desarrollo

¿En que otros escenarios se mantendria?
En el caso que la informacion de las aseguradoras cambien, pues solo se requiere cambiar la homologacion actual de datos por la nueva, sera como un versionamiento.

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.

El aplicativo en este ejemplo es uno que permite dar apoyo en el cumplimiento a los requisitos de la norma ISO 9001:2015.

  1. Problemas que resuelve:
  • Facilitar la documentación del esquema organizacional de la empresa.
  • Tener una plataforma que permita evidenciar de manera efectiva las actividades que realizó el personal, para dar cumplimiento a los requisitos que exige la norma ISO 9001.
  • Mejorar el proceso de auditoría interno y externo.
  • Evidenciar si se realiza la mejora continua de los procesos de la empresa.
  • Tener una herramienta que permita mejorar la gestión de riesgos.
  1. Requerimientos no funcionales
  • La disponibilidad de la información en todo momento tanto para las personas que trabajan dentro de la organización como los que no.
  • La información de carácter no público deberá ser enviada en canales seguros que deben estar cifrados constantemente.
  • Facilitar la interacción al aplicativo a las personas externas a la organización. Auditores, Proveedores, Entidades Públicas y todo tipo de interesados deben tener a su alcance información clara y concisa de lo que requieran de la organización.
  • La información no debe alterarse bajo ninguna circunstancia por personas no autorizadas.
  • Se debe integrar con otros sistemas de la empresa de acceso al público, para medir el grado de satisfacción que tienen con nuestros servicios ofrecidos. Esto con el fin de identificar oportunidades de mejora e implementarlas en el Sistema de Gestión de la Calidad actual.
  1. ¿Cómo cambiaría su arquitectura en caso de que sea un producto reutilizable?

Se tendría que reevaluar la forma de documentar los procesos que exige la norma ISO 9001. La documentación está hecha a la medida de la empresa. En este escenario se debe buscar una forma de documentación de procesos que sea un estándar internacional, debemos apoyarnos de otras normativas ISO que formalicen mejor este proceso.

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

Si en la nueva version de la norma ISO 9001 cambian totalmente los requisitos de calidad exigidos. La arquitectura del aplicativo sufriría muchos cambios que van exigir rediseñar
su estructura interna.

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

Mientras no exista cambios significativos en la norma ISO 9001, y si estos cambios dependen de los que ya existen. Entonces solo debemos aumentar nuevas funcionalidades a nuestro aplicativo.

1.- ¿Qué problemas resuelve?
Presentar información en tiempo cuasi-real de la red de monitoreo ambiental de una region metropolitana de Colombia.

2.- Requerimientos no funcionales

  • El sistema ofrece la posibilidad de registrarse como usuario
  • El sistema presenta un sistema de autenticación de usuarios.

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

  • Separar el componente historico del componente real.
  • En la actualidad el sistema es monoilitoco, los procesos de ETL y generación de productos se hacen en el aplicativo web. Esto se debe separar

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

  • Cambiar de una BD relacional a una no relacional.

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

  • Presentación d einformacion de ciudad. Novedades de trafico, ocupación de medios de transporte.

Proyecto de una PWA para la venta de productos de repostería. Actualmente permite realizar un pedido de varios productos y se integra con métodos de pagos.

¿Cómo cambiaría su arquitectura?
Actualmente el BackEnd es un monolito, cuando la demanda aumente se podría crear micro-servicios para que controlen procesos separados como ser la búsqueda de productos, pagos, registros de clientes, puntuaciones del producto, etc.

¿En qué otro escenario debería repensarse completamente?
Seria si decidieran cambiar de rubro, ya que hay cosas desarrolladas y bastantes personalizadas para el rubro de la repostería.

¿En qué otros escenarios se mantendría?
Siempre y cuando se mantenga en la linea de venta de productos comestibles.

Software de secuestro y almacenamiento de carbono de ecosistemas: Resuelve el problema de saber como se comporta cada ecosistema en la captura y almacenamiento de carbono, para así entender que ecosistema puede capturar más, con cuales se podrá reforestar, etc.
RNF: Datos de cada uno de los ecosistemas, colecta de datos, sincronización, soporte, etc.
¿Cómo cambiaría su arquitectura?
Cambiando el modelo, o algoritmo dependiendo de qué otro sistema se pueda trabajar, como captura de otro elemento.
¿En que otro escenario debería repensarse completamente?
En el análisis de otro servicio ambiental.

Describir qué problemas resuelve y cuáles son sus requerimientos no funcionales.

SW para la facturación al cliente, a través de un POS (ERP Odoo)
RNF:
1)Funcionamiento sin conexión a internet
2)Recuperación en un tiempo menor a K segundos, al ocurrir una falla de impresión
3)Seguridad de los datos

Si tuvieras que hacer de este sistema un “producto reutilizable” en otros escenarios:
¿Cómo cambiaría su arquitectura?
1)Estructura de la API de conexión
2)Incorporaría microservicios

¿En qué otro escenario debería repensarse completamente?
Quizás pensaría en algún cambio cuando cambie de país y suceda alguna variación mayor en términos de restricciones propias del negocio
¿En qué otros escenarios se mantendría?
Se mantiene en toda empresa , que use un POS y además facture e imprima a través de una impresora fiscal

De un proyecto propio: Una landing page para una violinista.
Problemas que resuelve:

  • El manejo de una agenda, pues ahora será automatizada para la administradora.
  • El empalme de varios eventos.
  • Falta de publicidad para sus servicios.

Requerimientos no funcionales:

  • Una página llamativa y atractiva que informe a posibles clientes de los servicios que ella ofrece.
  • Una calendarización amigable para la administradora de la página.
  • Un servicio de pago seguro para el apartado de los servicios.
  • Un formulario de apartado fácil de usar.

Cómo cambiaría su arquitectura:

  1. Agregaría a la base de datos la tabla Administrador para que el usuario pueda crear la cantidad de páginas que desee.
  2. El administrador, en vez de tener una página diseñada a medida, tiene que ingresar el nombre de la página y la cantidad de urls de la página, el estilo y posición de navegador, seguido por un conjunto de layouts a esoger y llenar por el administrador.
  3. Cada administrador tiene una página para administrar las solicitudes de eventos.

Yo hice un sistema referido al registro de empresas para una certificación de la Unidad de Bomberos en mi país, el enfoque es que por medio de requisitos que deben cumplir las empresas tanto publicas como privadas y sean validadas por la institución les dan una cerficiación para poder emprender el negocio y/o seguir con sus funciones, como todo sistema tuve que ir creciendo todo el tiempo en cuestión de funcionalidades, lo que hice que muchas veces tuve que volver a realizar análisis y requerimiento, esto por que existe módulos para que las empresas puedan cargar información requerida para la certificación, para poder ayudar a las empresas se fue modificando el modo de programación para que no tengan ningún problema al momento de cargar toda esa información.

El proyecto es un banco de información de datos sobre la salud.

El problema que resuelve es poder centralizar los datos en un solo banco de información (de una alcaldia) el cual consolide la información final y sea capaz de ofrecer indicadores y estadísticos de utilidad y de interés.

Algunos de los requerimientos no funcionales que percibo son:

  • Autenticación y cifrado seguro
  • Disponibilidad del banco de información
  • Comunicación asíncrona y en tiempo real
  • Escalabilidad del sistema
  • Integridad de los datos

Si tuviera que hacer ese sistema como un producto reutilizable en otros escenarios:

  • Cambiaría un poco la arquitectura para ajustar algunos componentes que permitan interactuar de manera mas “dinamica” o “parametrizable” con el fin de evitar generar una nueva implementación del sistema. Con esto estaría implicito el tema de agregar un par de componentes que permitan distribuir o balancear la carga de los sistemas de backend o de bases de datos con el fin de soportar mucho mas trafico y concurrencia asi como tambien más almacenamiento.

  • Diría que otro escenario donde deberia replantarse la arquitectura va a depender mucho del problema que realmente se quiere atacar y los recursos que se dispongan para la implementación de la misma.

  • Otros escenarios donde se mantendría es no solo para construir un banco de información de salud, sino es una arquitectura que sirve para cualquier proyecto de ingeniería de datos que requiera de ejecutar procesos en segundo plano que esten consultanto/actualziando información. Además es una buena base para la comunicación via eventos y actualizacion de bases de datos en tiempo real.

Mi proyecto es un sistema donde estudiantes de niveles superiores de universidades con capacidades aprendidas por fuera de dichas universidades puedan subir videos y crear cursos de niveles estudiantiles con los que enseñar a otros estudiantes contenidos que no se comprenden en dicha maya estudiantil.
Considero que si es un producto reutilizable dado que este contesto fue desarrollado para una universidad con énfasis tecnológicas, pero este tema es un fundamento imprescindible en todas las universidades, dado que estudiantes con cierta capacidad puede dar su experiencia a otros estudiantes, dado que muchos no se orientan necesariamente por lo enseñado en la universidad, basándome en el contesto de que la universidad en la que estudie no esta adaptada a lo que se requiere actualmente en el mundo laboral (Mi carrera es Ingeniería de sistemas, soy estudiante de Colombia, y vivo en una ciudad bastante pequeña).

Cambio de arquitectura: Su arquitectura esta basada en una modularizacion, por lo tanto reestructuraría estrictamente lo necesario, dado que los componentes los diseñe para que se adaptaran.

En que otro escenario debería repensarse…: Probablemente si se quiere utilizar la idea en contextos de universidades que intervienen de forma directa con la salud de personas, ejemplo: Universidades con énfasis en ciencias básicas o Medicina.

En que otro escenarios se mantendría: Probablemente en materias fundamentales, o como proyecto social con la intención esparcir conocimientos básicos u oportunidad de dar conferencias dentro de la app (El proyecto es una aplicación movil desarrollada con tecnologías como Flutter, Go, Docker, Kubernetes, entre otras).

Si te parece interesante por favor deja aquí tu comentario.
Saludos.

El sistema es para reservaciones en locales gastronómicos, restaurantes o bares.

Problemas a resolver

  • Fortalecer el uso de la tecnología en los entornos gastronómicos para sobre llevar en esta situación actual (pandemia por COVID-19)
  • Mejora en la atención al cliente
  • Garantizar un orden estratégicos de volumen de clientes y el espacio a ser considerados en un tiempo relativamente rápido
  • Motivar el uso de la herramienta tecnológica con el fin de ser innovadores en un entorno de constantes avances

Requerimiento nos funcionales

  • Agilidad en la reserva de mesas
  • Visualizar la disponibilidad de mesas en tiempo real
  • Accesibilidad / Portabilidad
  • Seguridad
  • Conexión a red

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

  • ¿Cómo cambiaría su arquitectura?
    Dado que este es un sistema hecho para la universidad, por motivos de haber tenido muy poco tiempo en su creación y diseño, tendría muchos cambio por hacer en su arquitectura. Especialmente porque fue pensada para ser una pagina web, siento que estaría mejor siendo que sería mejor como una aplicación móvil para que este más disponible al usuario

  • ¿En qué otro escenario debería repensarse completamente?
    Realmente muchos escenarios, fue pensado en una vista más general y se pasaron por alto muchas cosas durante su creación para que sea “más sencillo de programar”.

  • ¿En qué otros escenarios se mantendría?
    Mantendría la base de datos, PostgreSQL, ya que es multiplataforma y obtenemos seguridad en el manejo de la información.

Sistema para gestionar las interacción entre un agente de soporte al cliente y un usuario de videojuegos para móviles.

  • ¿Qué problemas resuelve?

    Esta aplicación web permite concentrar en un entorno ordenado, las inquietudes y solicitudes a nivel global de los jugadores de un juego de móvil, para mejorar su experiencia en el juego y el manejo de sus cuentas, incluyendo los pagos. De esta forma, se responden los casos manteniendo los niveles de servicio y teniendo control completo sobre cada una de las entradas, permitiendo filtrar los casos por diferentes parámetros para una consulta más ágil.

  • Requerimientos no funcionales:

    • Permitir la consulta al área de soporte de forma ágil desde el juego o desde un formulario web.
    • Proteger la información del jugador de acuerdo a requerimientos internacionales sobre información personal.
    • Permitir la compilación de la información del usuario siempre que este lo solicite y con pleno conocimiento de sus derechos legales.
    • Brindar seguridad en cada una de las transacciones que el jugador realice para obtener la moneda del juego.
    • Compartir información útil, ágil y acertada sobre cada uno de los aspectos del juego.
  • Reutilziación del producto:

    • Arquitectura: Dado que el agente de soporte es el principal usuario del sistema, mantendría una comunicación constante para conocer su feedback y mejorar los aspectos que puedan agilizar la asistencia al jugador. A partir de este feedback, mejoraría cada vez más la interfaz y crearía herramientas que permitan automatizar procesos que se puedan realizar de forma repetitiva. De igual forma, me encargaría de realizar una documentación detallada de cada cambio, para que tanto los usuarios antiguos como nuevos puedan capacitarse constantemente.
    • Otro escenario: Debería repensarse esta estructura en función del juego y del tipo de interacción que el jugador necesite. Por ejemplo, si la interacción debe ser sincrónica o asincrónica; barreras de tipo idiomático o cultural; requerimientos propios del juego.
    • Se mantendría: en escenarios donde los juegos desarrollados compartan características similares en cuanto a jugabilidad, uso de moneda del juego, microtransacciones, sistema de recuperación de cuentas, sistema de protección de datos.

Sistema
Una pagina web que le enseña a los usuarios los autobuses en tiempo real.
Requerimientos No Funcionales
Busqueda de parada, seleccon de ruta especifica, planificacion de viaje, UI facil de usar y zoom para ver mejor el mapa.
Como cambiaria su arquitectura
Cambiaria para que use la ubicacion actual del usuario para enseñar paradas mas cercanas y que le de rutas alternas para llegar a su destino.
En que otro escenario deberia de repensarse completamente
Si estan en otra cuidad tome la ubicacion y le muestre las rutas de ahi sin que tenga que cambiar manualmente o usar otra pagina web/app para ver las rutas.
En que otros escenarios se mantendria
Se mantendria si hay metodos no oficiales de transporte en la cuidad que tengan una ruta especifica.

Sistema: Syslog server en aws.
Problema que resuelve: Limitaciones de almacenamiento en equipos distribuidos clientes.

Requerimientos no funcionales: Disponibilidad, Seguridad debido a la sensibilidad de los datos, encriptacion unica por cliente.

Si fuera un producto reutilizable:
Creacion de Software web para la visualizacion de datos.
Si fuera a recibir datos de dispositivos de distintos vendors habria que repensar la compatibilidad del protocolo para distintos equipos.
Se mantendria en los escenarios que los distintos equipos fueran capaces de enviar datos sin problema sin reutilizar IPs para equipos (NAT)

Poner en práctica lo aprendido

*PROYECTO:
-> Implementacion de Arquitectura para Emision Intantanea & Bactch de trajetas EMV

PROBLEMA QUE RESUELVE:
-> La gestion inmediata de tarjetas EMV y el la emision del producto en menos de 5 min

-> satisfaccion y comodidad del cliente para la perdida , renovacon de tarjetas EMV
-> Dispensar tarjetas mediente un kiosco Totem

*REQUERIMIENTOS FUNCIONALES:
-> Metodo de activacion de tarjetes
-> Emision de tarjeta contacless
-> confidencialidad en encriptacion de datos
-> Facil manejo de Dasboard en el equipamiento

*REQUERIMIENTOS NO FUNCIONALES:
-> Sistema totalmente automatizado capaz de recuperarse asi mismo
-> Descuentos de tarjetas en stock automatizadas
-> Monitorear el equipo y las trasacciones insertadas en la base de datos

Sistema: Aplicación para revisión de cvs
Problemas que resuelve: Ahorro de tiempo de checar cvs uno por uno, administrar el personal con el que se cuenta, evaluar eficientemente un cv, capacidad de encontrar una habilidad entre todo el personal disponible.
Requerimientos no funcionales: Fiabilidad, interoperabilidad, persistencia de datos, disponibilidad y accesibilidad.
¿Cómo cambiaría su arquitectura?
Lo volvería modular para poder quitar y agregar módulos conforme lo demande la empresa que lo tenga en uso, verificación de coexistencia con otros programas en el mismo ambiente, así como la tolerancia a fallos desconocidos que podrían surgir.
¿En qué otro escenario debería repensarse completamente?
Si es usado por una empresa con una gran cantidad de datos podría ralentizar el sistema; también que usen un sistema operativo diferente al que se desarrolló, por lo que debería modificarse para soportarlo.
¿En qué otros escenarios se mantendría?
En empresas pequeñas donde el software no tenga un uso intensivo durante todo el día y que no traten con una gran cantidad de datos.

Sistema: Sistema de administracion de barberia
Problema: una barberia en creciemiento requiere un sistema para llevar la contabilidad de las ventas, registro del trabajo de los empleados e informacion de los clientes, tambien necesita la capacidad de montar ofertas ocasionalmente de manera manual o programarlas con antelacion.
¿Como cambiaria su arquitectura?
Suponiendo que se volviera un gran negocio con varias sedes pasaria el sistema a una arquitectura basada en microservicios
¿En qué otro escenario debería repensarse completamente?
Su alojamiento en servicios completamente gratuitos, el sistema esta pensado para seguir el creciemiento del negocio mientras se mantenga con una sola sede, en caso de expansion debe repensarse el modelo completo de la base de datos
¿En qué otros escenarios se mantendría?
Puede mantenerse en cuaquier negocio pequeño o mediano reiterando mientras mantenga una sede, de lo contrario no habria forma de filtrar la procedencia de la informacion

El proyecto es un sistema de recaudo de Impuestos
El sistema permite administrar tener registrado los recaudos realizados a través de los diferentes canales como lo es: Oficinas, medios electrónicos (PSE, ATH, Credibanco)

Los requerimientos no funcionales de este sistema son seguridad , portabilidad, sincronización.

¿Cómo cambiaría su arquitectura?
El sistema actualmente tiene una arquitectura monolítica, lo cambiaría arquitectura orientada a microservicios.

¿En qué otro escenario debería repensarse completamente?
El sistema a pesar de sirve para tener control de los recaudos realizados, no sirve el 50% de la aplicación debido a que hay muchas de las funcionalidades existentes se encuentran obsoletas y por ende genera reprocesos al momento de entregar la información de lo recaudado a los entes de control.

¿En qué otros escenarios se mantendría?
Para cualquier proceso que tenga ver con análisis de información y de procesamiento de datos.

El proyecto es un sistema para una inmobiliaria que permite la publicación de inmuebles en múltiples portales online (como MetroCuadrado o FincaRaíz) de forma simultánea.

Problemas que resuelve: Como agente inmobiliario, quiero recopilar y distribuir eficientemente la información del inmueble a comercializar, en los portales online más grandes del país, para darles mayor visibilidad sin hacer reprocesos en su publicación.

Requerimientos no funcionales:

  1. Eficiencia/Rápido.
  2. Sencillo/Simple.
  3. Mayor alcance y visibilidad posibles para el inmueble.

¿Cómo cambiaría su arquitectura si fuera reutilizable?

  • El módulo principal de publicación debería ser compatible con N sub-módulos, uno para cada portal de tercero a implementar, independientemente de los atributos que cada API del tercero espere en su cuerpo. Ese módulo principal debería ser lo suficientemente inteligente como para distinguir qué contenido enviar a cada sub-módulo.

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

  • Debería replantearse completamente en un escenario en que la información del inmueble no deba publicarse en portales de terceros, sino en una base de datos interna para la gestión de dichos inmuebles a modo de CRM.

¿En qué otros escenarios se mantendría?

  • Se mantendría en escenarios en los que se requiere publicar un producto en múltiples portales de manera simultánea. Por ejemplo, si quiero vender un carro puedo usar un sistema con arquitectura similar para distribuirlo en TuCarro y demás portales afines desde una misma plataforma.

Sistema para mostrar publicidad y numeradores para filas en un supermercado.

Problemas que resuelve: cambiar la publicidad de todas las sucursales de una sola vez y permitir que el usuario vea el numero de fila del servicio que esta esperando mientras pasea por el mercado en varios sectores.

Requerimientos no funcionales: cambiar numeradores en tiempo real, cambiar publicidad en tiempo real, poder ver el numero de fila y ofertas en cualquier parte de supermercado para no tener que estar esperando en la fila.

Producto reutilizable: Haría una versión genérica parar cualquier negocio que tenga filas y quiera mostrar publicidad y a su vez que el usuario pueda obtener su numero de fila desde el móvil con un tiempo estimado de espera.

Sistema de seguimiento de Ordenes para tiendas

Problemas que resuelve

1) Seguimiento y surtido de ordenes a nivel tienda
2) Consulta de información de ordenes en tienda
3) Módulos de reportes de ventas

Requerimientos no funcionales

1) Esquema DRP. Cuenta con esquema de DRP (Solo la base de datos)
2) Autenticación con AD. Cuenta con autenticación por Active Directory, lo cual mejora la seguridad para el caso de que haya bajas de personal.
3) Aplicación de escritorio. Es una aplicación cliente-servidor.
4) Monitoreo de la aplicación en tiempo real. Se pueden ver eventos de la aplicación en tiempo real.
5) Monitoreo de la salud del sistema en tiempo real. Algunos módulos tienen monitoreo de la salud de los servidores en tiempo real.
6) Arquitectura polling. Basada en consultas de estado entre la aplicación y la base de datos.
7) Base de datos on-premise.

Cambios para hacer un producto reutilizable

**Módulos que tendrían que re-pensarse**

1) Arquitectura orientada a eventos. Incluriria una arquitectura Publisher-subscriber para enviar las ordenes de forma inmediata hacia los clientes, sean estos un aplicación mobile o web, y en otros casos en donde tenga sentido.
2) Cambiar la aplicación cliente-servidor por una aplicación mobile + web.
3) Crearía una serie de APIs que permitan interacciones específicas con los clientes.
4) Buscaría una arquitectura montada en la nube.
5) Buscaría un modelo de datos que pueda ser explotado fácilmente por áreas interesadas, con bajo esfuerzo para integración, que pueda extenderse fácilmente, y que esté aislado de la parte transaccional para evitar impactos de performance.

**Módulos que podrían permancer como son:**

1) Monitoreo de la aplicación en tiempo real.

Monitoreo de la salud del sistema en tiempo real.

Sistema de soporte bibliográfico para investigaciones Universitarias.

Problema que resuelve:

  • Búsqueda de uno o varios términos en múltiples archivos de texto
  • Generación de citas bibliográficas en diferentes formatos (apa, etc.)

Requisitos no funcionales:

  • búsquedas optimizadas de los términos
  • universalidad en cuanto a los formatos de texto que acepta el sistema
  • interfaz amigable y sencilla

¿Cómo cambiaría su arquitectura?

  • Integraría opciones mas avanzadas para procesar texto a partir de imágenes o documentos escaneados y así aumentar la verstatilidad del sistema
  • El proceso anterior se tendría que complementar con poder de computo en la nube con el fin de ejecutar los diversos procesos que pueden ralentizar al dispositivo del usuario final

¿En qué otro escenario debería repensarse completamente?
Si se decide ampliar las funcionalidades del software en ámbitos legales para el proceso de documentos judiciales, es posible que haya que replantear algunas características debido a las particularidades de la escritura, jerga, etc, de los textos legales.

¿En qué otros escenarios se mantendría?
Si se quiere extender el mercado hacia periodistas y medios de comunicación para el procesamiento de documentos en sus investigaciones y reportajes, no habria mayor problema en mantener la misma arquitectura del sistema universitario