¿Cuánto diseño ocurre en su fase de implementación?

7

Para aquellos de ustedes que trabajan en grandes grupos de diseño inicial / cascada: ¿cuánto se omite el pensamiento crítico y el diseño en su fase de diseño y se deja en la fase de implementación? ¿Cuán completas y detalladas están sus especificaciones funcionales y técnicas entregadas al final de la fase de diseño?

Me parece que hay mucho espacio para la interpretación en el nivel de detalle que se debe proporcionar al final de la fase de diseño, y me molesta que la fase de diseño sea apresurada y luego los gerentes se enojen porque la La fase de compilación no avanza como si estuviéramos produciendo widgets en una línea de ensamblaje. Por otro lado, una fase de diseño que es lo suficientemente completa como para que la fase de compilación funcione como una línea de ensamblaje incluye prácticamente la fase de implementación, todo lo que quedaría en "compilación" es escribir cosas en el editor. Por supuesto, también significa que su fase de diseño es gigantesca.

Me doy cuenta de que este es un defecto del modelo de cascada , pero si hay alguien por ahí que pueda brindar un consejo constructivo: ¿dónde se puede trazar la línea? ¿Cuáles deberían ser las expectativas para las fases de diseño y construcción, y qué tipos de fallas o errores de diseño no deberían o no deberían tolerarse en la fase de construcción?

    
pregunta nlawalker 30.10.2010 - 03:25

2 respuestas

6

Soy un gran fanático de la creación rápida de prototipos, el incremento rápido y la iteración rápida. Evolución más que "diseño inteligente". está escribiendo software para resolver problemas para las personas y las personas tienden a cambiar de opinión y necesidades a lo largo del tiempo, incluso en períodos cortos de tiempo.

es bueno tener requisitos, una vista aérea, y "firmar" lo más cuadrado posible antes de la codificación, pero hay poco sentido en ser dogmático, todo es fluido. prepárese para editar, enmendar y desechar el código a medida que avanza. Lo gracioso es que nunca llegas a un punto de finalización de todos modos ... la mayoría de los códigos parece cambiar mientras que las personas se preocupan por eso, y una vez que a nadie le importa, simplemente se elimina.

ahora para estar seguro de que esto no se aplicará a los bits de software que se deben realizar por primera vez como sistemas de control de aviones, controles de reactores nucleares, etc., pero supongo que no es su caso.

    
respondido por el Brad Clawsie 30.10.2010 - 06:07
5

Siempre hay algo perdido en la fase de diseño. Las personas son imperfectas, e incluso con una administración perfecta que permite un montón de tiempo de fase de diseño sin la presión para pasar a la implementación, habrá cosas que se perdió.

Del mismo modo, en el diseño, introduce un punto de rendimientos decrecientes. Por ejemplo, si diseña una interfaz de usuario y la escribe en una especificación, puede alcanzar rápidamente el punto donde la especificación contiene el diseño, el formato y toda la lógica de un formulario. En cuyo caso es bastante idéntico a la implementación, y quizás solo sean diferentes los bits de la cola del código.

Es necesario consultar el valor de llevar el diseño demasiado lejos: cuando el diseño se convierte en escribir el código porque esa es la forma más clara de transmitir su intención, es hora de preguntar si es suficiente.

La implementación, entonces, comenzará a descubrir cosas olvidadas o olvidadas, así como otros detalles de la implementación que podrían parecer fáciles pero que no lo son. (Tal vez los servicios que pensaste que podrías obtener de alguna biblioteca, o tu sistema operativo, no fueran como se esperaba ... y necesitas investigar un poco o escribir un montón de código nuevo como una solución alternativa, shim o parche.)

Waterfall es un modelo simple y encantador, ideal para explicar a la gerencia. También está bastante alejado del pensamiento iterativo y mixto de alto nivel / bajo nivel que sucede en la realidad.

Un comentario un poco más interesante sobre esto se puede encontrar en un libro más antiguo: "Declinación y caída del programador estadounidense" por Ed Yourdon.

Sé que esta no es una respuesta perfecta, pero luego, programación & Las metodologías de diseño tampoco son perfectas. El mejor enfoque para ellos es tratarlos como un sistema útil para hacer las cosas. Las reglas están ahí para AYUDARLE y para que se rompan cuando estorban. La ruptura de las reglas debe hacerse de manera inteligente, no simplemente porque alguien tuvo ganas de cortar el código desde el primer día.

    
respondido por el quickly_now 30.10.2010 - 06:02

Lea otras preguntas en las etiquetas