Concepto: Equilibrar las prioridades de los interesados que están enfrentadas
Este principio articula la importancia del equilibrio de las necesidad del interesado.
Descripción principal

Introducción

Este principio articula la importancia del equilibrio de las necesidades empresariales y de los interesados, que suelen entrar en conflicto, así como del equilibrio del desarrollo personalizado frente a la reutilización de activos en la satisfacción de esas necesidades.

    
Ventajas
  • Alinear las aplicaciones con las necesidades empresariales y del usuario
  • Reducir el desarrollo personalizado
  • Optimizar el valor empresarial
Patrón
  1. Definir, comprender y priorizar las necesidades empresariales y del usuario
  2. Priorizar los proyectos y requisitos y asociar las necesidades con las posibilidades del software;
  3. Comprender los activos que se pueden optimizar;
  4. Equilibrar la reutilización de activos con las necesidades del usuario
Antipatrones
  • Documentar profusamente los requisitos precisos al principio del proyecto, forzar al interesado a aceptar los requisitos
    • Negociar cada cambio de requisitos, con lo que cada cambio puede aumentar el coste y la duración del proyecto
    • Bloquear los requisitos de entrada, y así reducir la capacidad de optimizar los activos existentes
    • Realizar principalmente un desarrollo personalizado
  • Crear una arquitectura de sistema que sólo satisfaga las necesidades de los interesados que más se hacen notar.

Discusión

Por ejemplo, la mayoría de los interesados preferirían tener una aplicación que haga exactamente lo que ellos desean que haga, y a la vez minimizar el coste de desarrollo y el tiempo de planificación de la aplicación. Sin embargo, estas prioridades suelen estar en conflicto. Otro ejemplo es que si se optimiza una aplicación empaquetada, es posible que se pueda entregar una solución más rápida y a menor coste, pero habrá que realizar algunas concesiones con los requisitos. Si, por el contrario, optamos por construir una aplicación desde cero, ello puede hacer posible abordar cada requisito de la lista de deseos, pero es posible que el presupuesto y la fecha de finalización del proyecto se pospongan más allá de sus límites factibles.

El uso de un componente puede reducir de forma significativa los costes y la planificación para la entrega de un conjunto de funciones. En muchos casos, esto significa que se deben hacer concesiones en ciertos requisitos funcionales o técnicos, como el soporte a algunas plataformas, el rendimiento o el "footprint" (el tamaño físico de la aplicación).

Para poder equilibrar necesidades, primero se deben gestionar los requisitos con eficacia, tal como se describe en  Material de soporte: Gestión de requisitos. En lugar de enviar equipos de programación para que ataquen cada elemento de una lista de requisitos, necesitamos entender y priorizar las necesidades empresariales y de los interesados. Esto significa capturar los procesos empresariales y enlazarlos con los proyectos y las funciones del software, lo que nos permite priorizar con eficacia los proyectos y requisitos, y modificar nuestras prioridades a medida que va aumentando nuestro conocimiento sobre la aplicación y evolucionan las necesidades de los interesados. También significa que debemos implicar al cliente o a su representante en el proyecto para garantizar que comprendemos cuáles son sus necesidades.

A la vez, debemos centrar las actividades de desarrollo en torno a las necesidades de los interesados. Por ejemplo, al optimizar el desarrollo dirigido a guiones de uso y el diseño centrado en el usuario, nuestro proceso de desarrollo puede ajustarse a la evolución de las necesidades del interesado a lo largo del proyecto, como una función para negocios cambiantes y de nuestra capacidad mejorada de comprensión de las funciones que son realmente importantes para la empresa y para los usuarios finales.  

Finalmente, debemos saber qué activos están disponibles y equilibrar la reutilización de activos con las necesidades de los interesados. Los ejemplos de activos incluyen las aplicaciones heredadas, servicios, componentes reutilizables y patrones. La reutilización de activos puede, en muchos casos, suponer una reducción en el coste del proyecto. La reutilización de activos probados suele significar una mayor calidad de las nuevas aplicaciones. La contrapartida es que, con frecuencia, debe equilibrarse la reutilización de activos y la satisfacción completa de las necesidades del usuario. La reutilización de un componente puede reducir los costes de desarrollo de una función hasta un 80%, pero es posible que sólo cubra el 75% de los requisitos. Por tanto, una reutilización eficaz precisa que equilibremos constantemente la reutilización de activos con las necesidades del interesado, que son cambiantes.