¿Cuánto esfuerzo se debe poner en cada parte de un proyecto de cascada?

Donde la cascada comúnmente incluye:

1. Requisitos
2. Diseño funcional
3. Diseño técnico
4. Construir
5. Prueba
6. revisión
7. (Desplegar)

E iteraciones a través de esta lista. Si olvidé un paso, avísame.

Depende de muchos factores, que incluyen:

• El dominio (por ejemplo, pasaría más tiempo en los requisitos de un contrato de defensa que en un clon de Twitter)
• Los desarrolladores (si tienen experiencia en la construcción de sistemas similares con tecnología similar, por ejemplo, podría dedicar menos tiempo al diseño).
• Los clientes (la probabilidad de que los requisitos cambien afecta el tiempo que llevará esa fase)
• La criticidad del sistema (pasaré más tiempo probando el sistema de lanzamiento del transbordador espacial que el sistema de repetición StackExchange).

Le daría un desglose aproximado del porcentaje del esfuerzo total que le daría a cada sección, pero tendría un margen de error de +/- 10% en cada una de ellas en función de los factores anteriores, por lo que sería un poco sin sentido.

La mejor parte (y probablemente la única sigue siendo relevante) del Mes del Hombre Mítico (lamentablemente ahora desactualizado) es P.20, que divide el tiempo de un proyecto en 1/3 de planificación, 1/6 de codificación, 1/4 de prueba de componentes y 1/4 prueba del sistema, una muy buena división que lamentablemente se cumple muy poco.

1. Requisitos
2. Diseño funcional
3. Diseño técnico
4. Construir
5. Prueba
6. revisión
7. (Desplegar)

Puede dividir todos estos, o el grupo 2 y / o 1,2 y 3

¿4) build incluye prueba unitaria? ¿Qué es 5) prueba? Prueba unitaria, integración de software, integración de sistemas?

6) La revisión es un subconjunto de 1, 2 y 3

¿La escritura de las especificaciones de prueba unitarias es parte de 3) Diseño técnico?

Creo que debe pensar mucho más sobre lo que significan estas cosas y agregar un poco de granularidad.

Sin embargo, felicitaciones por pensar en esto, muy pocas personas lo hacen.