Arquitectura de Software: Adaptación y Escenarios de Uso

Clase 13 de 24 • Fundamentos de Arquitectura de Software (2018)

Contenido del curso

El proceso de desarrollo de software

Introducción a la arquitectura de software

Análisis de requerimientos

Estilos de arquitectura

Desarrollo del proyecto

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.

Comentarios

Gonzalo Godoy

student•

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.

Leonardo Andres Martinez Guevara

student•

Es mejor la arquitectura con python

Diego Castaño

student•

Excelente aporte.

Juan Camilo Castrillón García

student•

El proyecto es un sistema POS (Punto de venta)
El sistema permite administrar las ventas y el inventario y esta enfocado a restaurantes y bares.

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

¿Cómo cambiaría su arquitectura?
El sistema actualmente tiene una arquitectura monolitica, lo cambiaría a una arquitectura de capas y mas adelante a una arquitectura orientada a microservicios.

¿En qué otro escenario debería repensarse completamente?
El sistema a pesar de ser un POS, no sirve para ser utilizado en otro tipo de negocios diferentes a restaurantes y bares por eso debe ser rediseñado completamente.

¿En qué otros escenarios se mantendría?
Es importante tener en cuenta las experiencias ya vividas y debe adaptarse fácilmente a los tipos de negocios que actualmente soporta.

Francisco Genaro Cerna Fukuzaki

student•

Yo he visto que usan POS también en librerías, en cajas de universidades para realizar pagos de montos muy elevados, supermercados, farmacias. No me queda claro a qué te refieres con tu respuesta de en qué otro escenario debería repensarse completamente.

Jorge García

student•

Puede que el sistema de facturación POS por ser de fácil uso y confiable con el inventario sea llamativo a otros tipos de negocios. Un cliente interesado con un escenario distinto puede ser en el caso de negocios que venden a crédito y tienen entonces otras características y atributos en su proceso de venta. Allí seguramente hay que replantearse el sistema

Garry Junior Bruno Moncius

student•

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.

Manuel Alejandro Lopera Ospina

student•

Creo que esos requerimientos que describes son Funcionales.

Sergio Palacio

student•

descriibes requerimientos funbcionales como no funcionales

Olga Rodriguez Boulangger

student•

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.

Kevin Andrey Herrera Silva

student•

Sistema de corresponsal para transacciones bancarias Problemas que resuelve.

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

Requerimientos no funcionales.

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

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

Esteban Araya

student•

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.

Leonardo Andres Martinez Guevara

student•

Buen ejemplo.

Jose Mendoza

student•

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.

John Cardenas

student•

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.

José Guillermo

student•

Es curioso que WhatsApp siendo de Facebook haya implementado algunas de estas características solo en Messenger, ni siquiera en Instagram.

Andrés Madrigal

student•

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

Ubereats

¿Cómo cambiaría su arquitectura?
El método en que empacan y transportan la comida de los restaurantes asociados.
¿En qué otro escenario debería repensarse completamente?
El gasto que tienen desperdiciando tanto plástico puede ser evitado buscando soluciones alternas donde se reutilicen o conserven los componentes de almacenamiento y transporte
¿En qué otros escenarios se mantendría?
En el branding se puede usar ese movimiento como una campaña ecológica donde mostrara la preocupación por el ambiente y la Percepción que tienen las personas sobre las intenciones de la compañía por mejorar la comunidad.

**Nota: ** Hablo de buscar un método de almacenamiento re utilizable para evitar el consumo, pero el producto re utilizable en cuestión se trata de ubereats

Edson Contreras Pulido

student•

¿Existe algún framework , metodología o estándar para poder realizar la clasificación de requerimientos y analisis de riesgos ?

Marcos Lanuza

student•

En clases pasadas se habla de

Requerimientos funcionales y requerimientos no funcionales

Para los riesgos, la metodología sería ordenarlos y clasificarlos por nivel de urgencia e importancia, priorizando aquellos que sean de vital importancia para que el sistema no falle.

Jairo Sebastian Gil Madrid

student•

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.

Franklin Lucero

student•

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.

Arturo Sanchez

student•

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

Wendy Tatyana Romero Florez

student•

Con cuanto tiempo de anticipación se tendría las ordenes lista según el problema que describes y la solución que planteas¿?

Jorge Luis Ochoa Islas

student•

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

Franco Losardo

student•

Excelente idea la de la IA. Seria espectacular si la implementaran

Alejandra Yepes

student•

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.

TODO1 Colombia

student•

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.

Franco Damiani

student•

Sistema de Gestión de Riesgos Problemas que resuelve:

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

RNF:

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

Para hacerlo un producto reutilizable:

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

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

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

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

Jesus Ivan Villalobos de la Cruz

student•

Jair Israel Avilés Eusebio

student•

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.

Ignacio Romero

student•

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.

Arquitectura de Software: Adaptación y Escenarios de Uso

El proceso de desarrollo de software

Fundamentos de Arquitectura de Software: Decisiones y Roles Clave

Proceso de Desarrollo de Software: Etapas y Roles Clave

Problemas Esenciales y Accidentales en Desarrollo de Software

Roles en Desarrollo de Software Tradicional vs. Metodologías Ágiles

Introducción a la arquitectura de software

Fundamentos de Arquitectura de Software y su Aplicación Práctica

Estructuración de Equipos y Comunicación en Proyectos de Software

Roles y Requerimientos en la Arquitectura de Software

Arquitectura de Software en Metodologías Tradicionales y Ágiles

Análisis de requerimientos

Separación de Problema y Solución en Toma de Requerimientos

Requerimientos de Producto y Proyecto en Arquitectura de Software

Gestión de Riesgos en la Implementación de Sistemas

Restricciones en el Desarrollo de Software: Concepto y Ejemplos