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 comenzar la implementación del programa. A menudo se asocia con el modelo de cascada de desarrollo de software.
Los sinónimos de gran diseño por adelantado (BDUF) son gran modelado por adelantado (BMUF) y grandes requisitos por adelantado (BRUF). Estos se consideran antipatrones dentro del desarrollo de software ágil . [1]
Los defensores del modelo en cascada sostienen que el tiempo invertido en el diseño es una inversión que vale la pena, con la esperanza de que se dedique menos tiempo y esfuerzo a corregir un error en las primeras etapas del ciclo de vida de un producto de software que cuando se detecta ese mismo error y se debe corregir más adelante. Es decir, es mucho más fácil corregir un error de requisitos en la fase de requisitos que corregirlo en la fase de implementación, ya que corregir un error de requisitos en la fase de implementación requiere desechar al menos una parte del trabajo de implementación y diseño que ya se ha realizado.
Joel Spolsky , un popular comentarista en línea sobre desarrollo de software, ha argumentado firmemente a favor de un gran diseño desde el principio: [2]
"Muchas veces, pensar las cosas con antelación nos ahorraba serios dolores de cabeza en el desarrollo posterior... [al hacer un cambio en una especificación en particular]... Hacer este cambio en la especificación nos llevó una o dos horas. Si hubiéramos hecho este cambio en el código, habría añadido semanas al cronograma. No puedo expresar lo mucho que creo en el Gran Diseño por Adelante, que los defensores de la Programación Extrema consideran un anatema. He ahorrado tiempo y he creado mejores productos de manera constante usando 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 al respecto".
Sin embargo, varios comentaristas [3] [4] [5] han argumentado que lo que Joel ha llamado gran diseño por adelantado no se parece al BDUF criticado por los defensores de XP y otras metodologías de desarrollo de software ágil porque él mismo dice que su ejemplo no era reconociblemente el diseño completo del programa ni se completó completamente por adelantado: [6]
"Esta especificación es simplemente un punto de partida para el diseño de Aardvark 1.0, no un plan final. A medida que empecemos a desarrollar el producto, descubriremos muchas cosas que no funcionarán exactamente como lo habíamos planeado. Inventaremos nuevas funciones, cambiaremos cosas, perfeccionaremos la redacción, etc. Intentaremos mantener la especificación actualizada a medida que las cosas cambien. De ninguna manera se debe considerar esta especificación como una especie de ley sagrada y fijada en piedra".
Los críticos (especialmente aquellos que practican el desarrollo ágil de software ) argumentan que el BDUF es poco adaptable a los requisitos cambiantes y que el BDUF supone que los diseñadores pueden prever áreas problemáticas sin un prototipo extenso y al menos alguna inversión en la implementación. Para proyectos importantes, los requisitos de los usuarios necesitan refinarse en vista de los entregables iniciales, y las necesidades del negocio evolucionan a un ritmo más rápido que el de la finalización de los proyectos grandes, lo que hace que el Gran Diseño quede obsoleto cuando se completa el sistema.
También afirman que existe una sobrecarga que debe equilibrarse entre el tiempo que se dedica a la planificación y el tiempo que costaría realmente reparar un defecto. Esto a veces se denomina parálisis por análisis .
Si el costo de planificar es mayor que el costo de repararlo, entonces el tiempo invertido en planificar es un desperdicio.
La implementación continua , las actualizaciones automáticas y otras ideas relacionadas buscan reducir sustancialmente el costo de los defectos en la producción, de modo que sea más económico repararlos en tiempo de ejecución que planificarlos 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 los problemas durante el ciclo de desarrollo. Mejorar el software con el beneficio de los comentarios de los usuarios generalmente es menos costoso que tratar de anticipar y documentar cada aspecto 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). Por lo tanto, en BDUF se hacen muchas suposiciones que luego resultan ser falsas, pero que están diseñadas y posiblemente ya codificadas. [ cita requerida ]
Un enfoque alternativo es el diseño preliminar por adelantado [7] [8] [9] (RDUF), en el que se completa un diseño "suficiente" por adelantado para proporcionar un marco sobre el cual desarrollar los detalles del diseño a medida que avanza el proyecto.
Joshua Kerievsky ha denominado un enfoque similar "diseño suficiente" : [10]
"Lo que digo es que necesitamos una alta calidad de diseño para cosas que son críticas para nuestros productos y una menor calidad de diseño para cosas que no son críticas".
Los defensores de Scrum hacen referencia al concepto de diseño emergente : [11]
"La diferencia en un proyecto Scrum no es que se descarte el diseño intencional, sino que se hace (como todo lo demás en un proyecto Scrum) de forma incremental".
Comience con una idea de diseño preliminar