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 comience su implementación. A menudo se asocia con el modelo en cascada de desarrollo de software.
Sinónimos de gran diseño inicial (BDUF) son gran modelado inicial (BMUF) y grandes requisitos iniciales (BRUF). Estos se consideran antipatrones dentro del desarrollo ágil de software . [1]
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 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 encuentra el mismo error y debe corregirse más adelante. . Es decir, es mucho más fácil corregir un error de requisitos en la fase de requisitos que corregir ese mismo error en la fase de implementación, ya que corregir un error de requisitos en la fase de implementación requiere eliminar al menos parte del trabajo de implementación y diseño que se ha realizado. ya ha sido completado.
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 de antemano nos ahorró serios dolores de cabeza de desarrollo más adelante... [al hacer un cambio de especificación particular]... Hacer este cambio en la especificación tomó una o dos horas. Si hubiéramos hecho este cambio en código, habría agregado semanas al cronograma. No puedo decirles cuán firmemente creo en Big Design Up Front, que los defensores de Extreme Programming consideran anatema. He ahorrado tiempo constantemente y he creado mejores productos usando BDUF y yo. Estoy orgulloso de usarlo, sin importar lo que afirmen 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 [3] [4] [5] han argumentado que lo que Joel ha llamado gran diseño inicial 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 era reconocible. el diseño completo del programa ni se completó por completo por adelantado: [6]
"Esta especificación es simplemente un punto de partida para el diseño de Aardvark 1.0, no un plano final. A medida que comencemos a construir el producto, descubriremos muchas cosas que no funcionarán exactamente como estaba planeado. Inventaremos nuevas características, cambiaremos cosas, refinaremos la redacción, etc. Intentaremos mantener la especificación actualizada a medida que las cosas cambien. De ninguna manera debes considerar esta especificación como una especie de sagrada e incorporada. -ley de piedra."
Los críticos (en particular aquellos que practican el desarrollo ágil de software ) argumentan que BDUF se adapta mal a los requisitos cambiantes y que BDUF supone que los diseñadores son capaces de prever áreas problemáticas sin una extensa creación de prototipos y al menos alguna inversión en implementación. Para proyectos importantes, los requisitos de los usuarios necesitan refinarse a la luz de los entregables iniciales, y las necesidades del negocio evolucionan a un ritmo más rápido que el de los proyectos grandes, lo que hace que el Gran Diseño quede obsoleto cuando se completa el sistema.
También afirman que existe un gasto general que debe equilibrarse entre el tiempo dedicado a la planificación y el tiempo que realmente costaría solucionar un defecto. Esto a veces se denomina parálisis del análisis .
Si el costo de la planificación es mayor que el costo de la reparación, entonces se desperdicia 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 resulte más barato solucionarlos en tiempo de ejecución que planificarlos al 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 suele ser menos costoso que tratar de anticipar y documentar cada aspecto de un sistema con BDUF.
Además, en la mayoría de los proyectos existe una falta significativa de requisitos escritos completos (o incluso bien conocidos). Entonces, en BDUF se hacen muchas suposiciones que luego resultan ser falsas, pero que están diseñadas y posiblemente ya codificadas. [ cita necesaria ]
Un enfoque alternativo es el diseño aproximado por adelantado [7] [8] [9] (RDUF), en el que se completa un diseño "suficiente" por adelantado para proporcionar un marco sobre el cual construir los detalles del diseño a medida que avanza el proyecto.
Joshua Kerievsky ha denominado diseño suficiente un enfoque similar: [10]
"Estoy diciendo que necesitamos alta calidad de diseño para cosas que son críticas para nuestros productos y menos calidad de diseño para cosas que no son críticas".
Los defensores de Scrum se refieren 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 aproximada