Gran diseño al frente - Big Design Up Front
Big Design Up Front ( BDUF ) es un enfoque de desarrollo de software en el que el diseño del programa debe completarse y perfeccionarse antes de que se inicie la implementación de ese programa. A menudo se asocia con el modelo de cascada de desarrollo de software.
Argumentos para
Los defensores del modelo en cascada argumentan que el tiempo dedicado al diseño es una inversión que vale la pena, con la esperanza de que se invierta menos tiempo y esfuerzo en corregir un error en las primeras etapas del ciclo de vida de un producto de software que cuando se encuentra el mismo error y debe corregirse posteriormente . Es decir, es mucho más fácil corregir un error de requisitos en la fase de requisitos que corregir el mismo error en la fase de implementación, ya que para corregir un error de requisitos en la fase de implementación es necesario eliminar al menos parte del trabajo de implementación y diseño que se ha realizado. ya se ha completado.
Joel Spolsky , un popular comentarista en línea sobre desarrollo de software, ha argumentado firmemente a favor de Big Design Up Front:
"Muchas veces, pensar las cosas con anticipación nos ahorró serios dolores de cabeza de desarrollo más adelante. ... [sobre hacer un cambio de especificación en particular] ... Hacer este cambio en la especificación tomó una hora o dos. Si hubiéramos hecho este cambio en código, habría agregado semanas al programa. No puedo decirles cuánto creo en Big Design Up Front, que los defensores de la programación extrema consideran un anatema. Siempre he ahorrado tiempo y he creado mejores productos utilizando BDUF y Estoy orgulloso de usarlo, sin importar lo que digan los fanáticos de XP. Simplemente están equivocados en este punto y no puedo ser más claro que eso ".
Sin embargo, varios comentaristas han argumentado que lo que Joel ha llamado Big Design Up Front no se parece al BDUF criticado por los defensores de XP y otras metodologías ágiles de desarrollo de software porque él mismo dice que su ejemplo no fue reconociblemente el diseño completo del programa ni se completó completamente por adelantado:
"Esta especificación es simplemente un punto de partida para el diseño de Aardvark 1.0, no un plan final. Cuando comencemos a construir el producto, descubriremos muchas cosas que no funcionarán exactamente como se planeó. Inventaremos nuevas características, cambiaremos cosas, refinaremos la redacción, etc. Intentaremos mantener la especificación actualizada a medida que cambien las cosas. De ninguna manera debe considerar esta especificación como una especie de sagrada -la ley de la piedra ".
Argumentos en contra
Los críticos (especialmente aquellos que practican el desarrollo de software ágil ) argumentan que BDUF se adapta mal a los requisitos cambiantes y que BDUF asume que los diseñadores pueden prever áreas problemáticas sin prototipos extensos y al menos alguna inversión en implementación. Para proyectos sustanciales, los requisitos de los usuarios deben refinarse a la luz de los entregables iniciales, y las necesidades de la empresa evolucionan a un ritmo más rápido de lo que se completan los grandes proyectos, lo que hace que el Gran Diseño quede obsoleto cuando se completa el sistema.
También afirman que hay que equilibrar los gastos generales entre el tiempo dedicado a la planificación y el tiempo que realmente costaría arreglar un defecto. Esto a veces se denomina parálisis de análisis .
Si el costo de la planificación es mayor que el costo de la reparación , se pierde el tiempo dedicado a la planificación.
La implementación continua , las actualizaciones automáticas y las ideas relacionadas buscan reducir sustancialmente el costo de los defectos en la producción para que sean más baratos de solucionar en tiempo de ejecución que de planearlos desde el principio. En realidad, las correcciones en tiempo de ejecución son mucho más costosas que las correcciones de diseño, por lo que es fundamental utilizar métodos ágiles, como demostraciones frecuentes y comentarios de los usuarios durante el desarrollo para solucionar problemas durante el ciclo de desarrollo. Mejorar el software con el beneficio de los comentarios de los usuarios es generalmente menos costoso que intentar anticipar y documentar todos los aspectos de un sistema con BDUF.
Además, en la mayoría de los proyectos hay una falta significativa de requisitos escritos completos (o incluso bien conocidos). Entonces, en BDUF se hacen muchas suposiciones que luego resultan ser falsas, pero están diseñadas y posiblemente ya codificadas.
Alternativas
Un enfoque alternativo es Rough Design Up Front (RDUF) en el que se completa el diseño "suficiente" desde el principio para proporcionar un marco sobre el cual construir los detalles del diseño a medida que avanza el proyecto.
Un enfoque similar ha sido llamado Sufficient Design por Joshua Kerievsky:
"Estoy diciendo que necesitamos alta calidad de diseño para las cosas que son críticas para nuestros productos y menos calidad de diseño para las cosas que no son críticas".
Los defensores de Scrum se refieren al concepto de Diseño Emergente :
"La diferencia en un proyecto Scrum no es que se descarta el diseño intencional, sino que se hace (como todo lo demás en un proyecto Scrum) de forma incremental".