¿Por qué usar RAD?


Malas razones

  • Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo de costos).
  • Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en manejo de tiempo).

Buenas razones

  • Convergir tempranamente en un diseño aceptable para el cliente y posible para los desarrolladores.
  • Limitar la exposición del proyecto a las fuerzas de cambio.
  • Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del producto.


Calendario vs Presupuesto vs Calidad

  • Las concesiones determinan el ritmo de desarrollo.
  • Negociar algo que no sea el calendario de trabajo.
  • Una o más metas pueden ser inalcanzables.


Las concesiones determinan el ritmo del desarrollo

  • Desarrollo eficiente: equilibra calendario, presupuesto y calidad.
    • Calendario: más rápido que el promedio
    • Presupuesto: cuesta menos que el promedio
    • Calidad: mejor calidad que el promedio
  • RAD razonable: inclina la balanza hacia el tiempo más corto.
    • Calendario: mucho más rápido que el promedio
    • Presupuesto: cuesta poco menos que el promedio
    • Calidad: calidad poco mejor que el promedio
  • RAD a fondo: "programar a lo bestia".
    • Calendario: más corto posible
    • Presupuesto: cuesta más que el promedio
    • Calidad: menor calidad que el promedio


Negociar algo que no sea el programa de trabajo
  • RAD tiene una buena posibilidad de éxito si el cliente está dispuesto a negociar precio o calidad.
  • RAD tiene una mejor posibilidad de éxito si el cliente está dispuesto a negociar precio y calidad.
  • Negociar la calidad no significa una mayor tasa de fallas sino un producto con menos funciones o menos eficiente.


Una o más metas pueden ser inalcanzables

  • El menor número posible de fallas: los desarrolladores pueden no tener la posibilidad de corregir fallas en algunos componentes de terceros.
  • Nivel más alto de satisfacción del cliente: algunos requisitos secundarios pueden ser sacrificados en aras del calendario.
  • El menor costo de desarrollo: comprar herramientas y componentes puede ser más caro que desarrollarlos.

No hay comentarios:

Publicar un comentario