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 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 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 ha 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: [1]
"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 añadido semanas a la programación. No puedo decirles lo firmemente que creo en Big Design Up Front, que los defensores de la programación extrema consideran un anatema. Constantemente he ahorrado tiempo y he creado mejores productos utilizando BDUF y yo 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 [2] [3] [4] 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 reconocible el diseño del programa completo ni se completó completamente por adelantado: [5]
"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 debería 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 del negocio 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 arreglar en tiempo de ejecución que de planearlos 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 es generalmente menos costoso que tratar de 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 completos por escrito (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. [ cita requerida ]
Alternativas
Un enfoque alternativo es Rough Design Up Front [6] [7] [8] (RDUF) en el que se completa un 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: [9]
"Estoy diciendo que necesitamos una 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 : [10]
"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".
Ver también
Referencias
- ↑ Joel Spolsky (17 de agosto de 2005). "La especificación del proyecto Aardvark" . Joel en software . Archivado desde el original el 12 de abril de 2006 . Consultado el 26 de abril de 2006 .
- ^ "¡Una especificación de 20 páginas para un proyecto de 3 meses es una gran cosa! Pero no es BDUF, es SDUF" Rich Rogers [1] Archivado 2006-02-09 en Wayback Machine
- ^ "Desafortunadamente, mirando su especificación, parece tener poca relación con el tipo de BDUF contra el que se arrepienten XP (programación extrema) y otros programadores ágiles". Curt Sampson [2] Archivado el 18 de mayo de 2011 en la Wayback Machine.
- ^ "De todas las cosas que podría ser esta especificación, un gran documento de diseño inicial no es una de ellas". Kevlin Henney [3]
- ^ Joel Spolsky (17 de agosto de 2005). "Especificación funcional del proyecto Aardvark" (PDF) . Joel en software . Archivado desde el original (PDF) el 9 de mayo de 2012 . Consultado el 19 de julio de 2012 .
- ^ Täuber, Johannes. "... programación, material técnico, agilidad ..." Consultado el 19 de julio de 2012 .
- ^ "¿Cómo se diseñan sistemas complejos con TDD?" .
Comience con una idea de diseño aproximada
- ^ Sedley, Liz. "Diseño inicial tosco" .
- ^ Kerievsky, Joshua. "Diseño suficiente" . Blogic industrial . Consultado el 19 de julio de 2012 .
- ^ Cohn, Mike. "Diseño ágil: intencional pero emergente" . Blog de software de Mountain Goat . Consultado el 19 de julio de 2012 .