No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Reg铆strate

Comienza en:

4D
2H
53M
46S

Desarrollo del proyecto: PlatziServicios Fase Producto en crecimiento

22/24
Recursos

Aportes 33

Preguntas 5

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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)

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.

Guido, de que parte de argenina sos? Se te escap贸 un 鈥渢en茅s鈥 en este video jajajajaja, saludos desde Tucum谩n! @guiwoda

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