El proceso de desarrollo de software

1

Fundamentos de Arquitectura de Software: Decisiones y Roles Clave

2

Proceso de Desarrollo de Software: Etapas y Roles Clave

3

Problemas Esenciales y Accidentales en Desarrollo de Software

4

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

Introducción a la arquitectura de software

5

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

6

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

7

Roles y Requerimientos en la Arquitectura de Software

8

Arquitectura de Software en Metodologías Tradicionales y Ágiles

Análisis de requerimientos

9

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

10

Requerimientos de Producto y Proyecto en Arquitectura de Software

11

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

12

Restricciones en el Desarrollo de Software: Concepto y Ejemplos

13

Arquitectura de Software: Adaptación y Escenarios de Uso

Estilos de arquitectura

14

Estilos de Arquitectura de Software: Conceptos y Aplicaciones

15

Estilos de Arquitectura de Software: Llamada y Retorno

16

Estilos de Arquitectura de Flujo de Datos: Lote Secuencial y Tubos-Filtros

17

Estilos de Arquitectura de Software Centrada en Datos

18

Arquitectura de Componentes Independientes y Comunicación por Eventos

19

Comparación de Arquitecturas Monolíticas y Distribuidas

20

Calidad de Software: Atributos Clave y Mejoras

Desarrollo del proyecto

21

Análisis de Requerimientos en Desarrollo de Software

22

Gestión de Requerimientos y Seguridad en Servicios Empresariales

23

Arquitectura de Software para Expansión Global

24

Curso Profesional de Arquitectura de Software

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Gestión de Requerimientos y Seguridad en Servicios Empresariales

22/24
Recursos

¿Cuáles son los nuevos enfoques para llevar adelante el proyecto Platzervicios?

El crecimiento del proyecto Platzervicios trae consigo una serie de nuevos desafíos y oportunidades. A medida que el producto se expande, es crucial replantear los criterios de éxito y entender cómo satisfacer las demandas de un mercado cada vez más amplio. El enfoque se ha movido de clientes individuales a empresas, lo que implica ofrecer estabilidad y control de costos en las prestaciones de los servicios.

¿Cómo se adaptan los criterios de éxito?

Para las empresas clientes, el principal criterio es proporcionar estabilidad y control de costos. Las historias de usuario reflejan esta nueva dirección; por ejemplo, las empresas necesitan reportes detallados de los gastos en los servicios que consumen. Por otro lado, los prestadores de servicios buscan crecer junto a la plataforma, requiriendo reportes que muestren cuánto ingresan y el rendimiento profesional de sus empleados.

  • Clientes: Necesidad de reportes sobre gastos.
  • Prestadores: Necesidad de reportes sobre ingresos y rendimiento.

¿Cuáles son los nuevos requerimientos del sistema?

Con la nueva visión, surgen varios requerimientos clave. La generación de reportes se vuelve esencial, tanto específicos para gastos de clientes como los relativos a ingresos y horas de trabajo de los prestadores. Dada la complejidad de manejar esta información agregada, se debe analizar cómo integrarla eficientemente en la base de datos actual.

  • Requerimientos de reportes: Es necesario optimizar el sistema para que no se vea afectado al realizar cálculos en tiempo real.

¿Cuáles son los riesgos y retos de integración?

Uno de los riesgos al implementar estas nuevas funcionalidades es que las empresas no puedan extraer información del sistema fácilmente. Las empresas suelen tener ecosistemas establecidos y requieren que los nuevos productos se adapten al flujo de trabajo existente.

Otro riesgo es el jurídico: si las empresas descubren inexactitudes en la facturación, puede haber litigios. Por lo tanto, garantizar la precisión en las transacciones es fundamental.

  • Extracción de datos: Necesidad de integración con sistemas existentes.
  • Exactitud financiera: Minimizar riesgos legales asegurando transacciones precisas.

¿Qué estándares de seguridad y auditoría se deben tener en cuenta?

La comunicación entre empresas eleva la necesidad de cumplir con estándares de auditoría, mejorando la forma en que se graba y expone la información. Además, se debe prestar especial atención a la privacidad para proteger datos sensibles frente a potenciales ataques que pongan en riesgo a los clientes.

  • Estándares de calidad: Mejorar el manejo de la información.
  • Seguridad y privacidad: Proteger datos sensibles de las empresas.

¿Cómo afecta al estilo arquitectónico del sistema?

El estilo arquitectónico actual parte de una estructura cliente-servidor con una base de datos. El desafío más significativo es el manejo de reportes, que demanda una gran cantidad de recursos. Así que se sugiere separar la parte de reportes, trasladando la información de una base de datos transaccional a una de reportes para evitar costos en el servidor.

  • Separación de reportes: Transferencia de datos a una base de datos de reportes.
  • Estrategias de lectura: Implementar lotes secuenciales o una estructura de eventos.

En este contexto, es crucial estar al tanto de las últimas tendencias tecnológicas y del entorno legal para seguir mejorando y satisfaciendo las expectativas del mercado. Mantenerse informado y siempre buscar nuevas formas de optimizar Platzervicios será la llave para el éxito continuo.

Aportes 34

Preguntas 4

Ordenar por:

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

Nuestro sistema está creciendo, con eso llegan nuevos requerimientos, riesgos, stakeholders y una visión más amplia de lo que podemos solucionar.

Primero: Reevaluamos nuestros criterios de éxito
-Brindar a las empresas cliente estabilidad y control de costos de las prestaciones de servicios que necesiten
-Brindar a las empresas prestadoras una visión de crecimiento de sus servicios.

Luego, las historias de Usuario que salen de esta nueva visión:
-Como empresa cliente, necesito reportes de gastos en servicios para controlar y entender mis finanzas.
-Como empresa cliente, necesito generar listas de profesionales preferidos para nunca perder la disponibilidad del servicio
-Como empresa prestadora necesito medir el rendimiento de mis profesionales para comprender mi propio crecimiento.
-Como empresa prestadora necesito posicionarme como la mejor empresa del mercado para obtener más clientes.

Requerimientos:
Reportes
-De gastos por período y por tipo de servicio contratado
-De ingresos y horas trabajadas por profesional por periodo y tipo de servicio prestado

Autorización
-Gestión de Usuarios, roles y permisos asociados a acciones del sistema.

Posicionamiento y comunicación
-Ranking de prestadores por evaluación
-Lista priorizada de prestadores por tipo de prestación

Riesgos:
-Las empresas cliente no pueden extraer la información del sistema para integrar a sus aplicaciones existentes (normalmente ya existe un ecosistema de aplicaciones)
-Los indicadores de la empresa prestadora no son indicativos del trabajo realizado
-El proyecto podría recibir juicios de fraude por cobros injustificados.

Restricciones:
-Conformar estándares de auditoria profesional
-Garantizar la privacidad de los datos de consumo

**Estilo arquitectónico: **
El requisito más fuerte arquitectónico que debemos tener en cuenta pasa por los reportes.
Ahora nuestra base de datos se separa. Por un lado, dejamos lo transaccional en una base de datos y en otra, la que que se utilizará para los reportes, a fin de evitar el costo de la lectura de los reportes sobre una misma base de datos (y poner en el peligro toda la estructura de servicios que tenemos en este momento)

Guido, de que parte de argenina sos? Se te escapó un “tenés” en este video jajajajaja, saludos desde Tucumán! @guiwoda

Se repiten los mismos pasos que en la fase anterior, pero aquí se busca adaptar cada uno de los conceptos, es decir, puede que ocurran cambios o que aparezcan nuevos features en los criterios de exito, historias de usuario, requerimientos, riesgos y restricciones.

La arquitectura cliente-servidor es un modelo de diseño de software en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes.

Nuestro sistema está creciendo, con eso llegan nuevos requerimientos, riesgos, stakeholders y una visión más amplia de lo que podemos solucionar.

Primero: Reevaluamos nuestros criterios de éxito
-Brindar a las empresas cliente estabilidad y control de costos de las prestaciones de servicios que necesiten
-Brindar a las empresas prestadoras una visión de crecimiento de sus servicios.

Luego, las historias de Usuario que salen de esta nueva visión:
-Como empresa cliente, necesito reportes de gastos en servicios para controlar y entender mis finanzas.
-Como empresa cliente, necesito generar listas de profesionales preferidos para nunca perder la disponibilidad del servicio
-Como empresa prestadora necesito medir el rendimiento de mis profesionales para comprender mi propio crecimiento.
-Como empresa prestadora necesito posicionarme como la mejor empresa del mercado para obtener más clientes.

Requerimientos:
-Reportes
De gastos por período y por tipo de servicio contratado
De ingresos y horas trabajadas por profesional por periodo y tipo de servicio prestado

-Autorización
Gestión de Usuarios, roles y permisos asociados a acciones del sistema.

-Posicionamiento y comunicación:
Ranking de prestadores por evaluación
Lista priorizada de prestadores por tipo de prestación

Riesgos:
-Las empresas cliente no pueden extraer la información del sistema para integrar a sus aplicaciones existentes (normalmente ya existe un ecosistema de aplicaciones)
-Los indicadores de la empresa prestadora no son indicativos del trabajo realizado
-El proyecto podría recibir juicios de fraude por cobros injustificados.

Restricciones:
-Conformar estándares de auditoria profesional
-Garantizar la privacidad de los datos de consumo

**Estilo arquitectónico: **
El requisito más fuerte arquitectónico que debemos tener en cuenta pasa por los reportes.
Ahora nuestra base de datos se separa. Por un lado, dejamos lo transaccional en una base de datos y en otra, la que que se utilizará para los reportes, a fin de evitar el costo de la lectura de los reportes sobre una misma base de datos (y poner en el peligro toda la estructura de servicios que tenemos en este momento)

Crecimiento de un producto ya desarrollado:
- Criterios de Éxito: Si re-evaluamos los criterios de exitos para hacer llegar servicios de empresas a empresas (B2B).
- Historias de Usuario: Estas historias nos darán nuevos requerimientos.
- Requerimientos: se pueden definir nuevas necesidades y roles. (Aquí se Incluyen los Reportes)
- Riesgos
- Restricciones: Las nuevas restricciones que aparecen tienen que ver con estándares de Auditaría. Esto provoca que elevemos nuestros estándares de calidad.

Muy importarte está clase

Excelente Resumen

¿cuándo habla de costos de lectura a qué se refiere?

Nuestro sistema está creciendo, con eso llegan nuevos requerimientos, riesgos, stakeholders y una visión más amplia de lo que podemos solucionar.

Primero: Reevaluamos nuestros criterios de éxito
-Brindar a las empresas cliente estabilidad y control de costos de las prestaciones de servicios que necesiten
-Brindar a las empresas prestadoras una visión de crecimiento de sus servicios.

Luego, las historias de Usuario que salen de esta nueva visión:
-Como empresa cliente, necesito reportes de gastos en servicios para controlar y entender mis finanzas.
-Como empresa cliente, necesito generar listas de profesionales preferidos para nunca perder la disponibilidad del servicio
-Como empresa prestadora necesito medir el rendimiento de mis profesionales para comprender mi propio crecimiento.
-Como empresa prestadora necesito posicionarme como la mejor empresa del mercado para obtener más clientes.

Requerimientos:
-Reportes
De gastos por período y por tipo de servicio contratado
De ingresos y horas trabajadas por profesional por periodo y tipo de servicio prestado

genial

Ampliación a empresas:

Criterios de éxito:
- Brindar a las empresas cliente estabilidad y control de costos de las prestaciones de servicios que necesiten
- Brindar a las empresas prestadoras una visión de crecimiento de sus servicios

Historias de usuario:
- Como empresa cliente necesito reportes de gastos de servicio para controlar y entender mis finanzas
- Como empresa prestadora necesito medir el rendimiento de mis profesionales para comprender mi propio crecimiento

Requerimientos:
- Reportes: Reportes de gastos por periodo y tipo de servicio contratado
- Autorización: Gestión de usuarios, roles y permisos
- Posicionamiento y comunicación: Ranking de prestadores por evaluación

Riesgos:
- Las empresas cliente no puedan extraer la información del sistema para integrar en sus aplicaciones
- El proyecto podría recibir juicios de fraude por cobros injustificados

Restricciones
- Auditoria
- Privacidad

Estilo arquitectónico:
- Cliente servidor
Reportes: Lote secuencial

FASE PRODUCTO EN CRECIMIENTO
.

  • Análisis de los requerimientos del sistema.
  • Criterios de éxito.
  • Requerimientos técnicos.
  • Riesgos.
  • Restricciones:
    • Estándares de auditoria.
    • Privacidad de datos.

.
En el estilo arquitectónico actual se debe tener en cuenta que se esta partiendo de una decisión previa de una estructura definida.

Va creciendo el proyecto

Interesante!!

Muy bueno!

Veo un riesgo en el caso de las historias de usuarios:
Como empresa cliente necesito generar listas de profesionales preferidos para nunca perder la disponibilidad del servicio.

El riesgo sería que el profesional contratado podría llegar tener tanta confianza con la empresa, que la empresa lo contrataría por su parte, por ende la empresa ahorraría dinero ya que no le paga al intermediario.

Gracias

Que clase tan interesante! Ver el progreso del proyecto en cada fase.

muy bueno !

conforme avanza la aplicación también se incrementa la complejidad y hay que revaluar los requerimientos, riesgos y restricciones para adecuarnos a esta nueva versión también se tiene que evaluar el costo que las nuevas funcionalidades van a tener sobre lo ya implementado y de ser necesario agregar mas infraestructura.

Gracias por el resumen gente. Me ayudan a documentar mi curso

Hay que tener en cuenta que independientemente del estilo arquitectónico que elijamos ya estamos partiendo de una decisión previa

Excelente Ejemplo para ver la Arquitectura de Software es dinámico y varia de acuerdo cambian los requerimientos de negocio, de usuario , los riesgos. Y la arquitectura de hoy ya no sera la misma en la arquitectura en unos años o inclusos unos meses de mi sistema.

Como se planteria la arquitectura de eventos para el ejemplo expuesto???

La información es clara y se debe ser bastante objetivo para estructurar acertadamente la arquitectura del proyecto. Excelente explicación!

Producto en crecimiento:
Al revaluar los criterios de éxito no solamente abarcamos las necesidades de nuestros clientes o empresa/clientes, sino que ya estaríamos abarcando una visión mas extendida en nuevos mercados.

Super ejemplo 😃 muy bueno gracias

Muy excelente todo

La empresa creció y ahora tiene nuevos retos.
Estos desarrollos deberían haber estado en medio del curso, no al final.

Nuestra startup está teniendo exito como sistema y así mismo hemos de necesitar de nuevos requerimientos para llegar a la mayor cantidad de clientes posible.
Análisis de requerimientos:
Criterios de exito:
Brindar con nuestro servicio a empresas clientes estabilidad y control de costos de las prestaciones de servicios que se necesiten.
Se tiene una visión en el circulo de empresas prestadoras una visión de crecimiento de sus servicios.
Historias de usuario:
El empresario cliente x quiere llevar control de sus finanzas mediante el reporte de gastos en servicios.
El empresario cliente y necesita que halla un grupo de profesionales preferidos para nunca perder la disponibilidad de nuestro servicio.
El empresario prestador x quiere medir el redimiento de sus profesionales.
El empresario prestador y quiere posicionarse mejor en el mercado para obtener más clientes
Requerimientos:
Reportes: Gastos por período, por el tipo de servicio contratado, ingresos, horas trabajadas por el profesional por período y tipo de servicio prestado.
Autorización:
Gestión de usuario: El tipo de empleado que va a tener la empresa.
Roles
Permisos asociado a accines del sistema
Posicionamiento y comunicación: Ranking de prestadores por evaluación, lista priorizada de prestadores por tipo de prestación.
Riesgo
Las empresas clientes no tienen como extraer información del sistema debido a que estas manejan sus propia información.
Los juicios hechos por las misma empresas prestadoras de acuerdo con los fraudes.
Restricciones
Cumplir con estándares de auditoría profesional para que nuestro software sea seguro.
Garantizar la privacidad de datos de consumo