Antes, que trabajaba en una empresa de servicios, era un firme defensor del desarrollo de software mediante el enfoque clásico.

En este enfoque es imprescindible tener el proyecto lo mejor definido posible en el análisis de requerimientos, realizar las fases de análisis funcional y técnico, y finalmente abordar el desarrollo y las pruebas de calidad.
Los análisis de requerimientos, y funcional, debían ser revisados y validados por el cliente, y eso era la biblia para la implementación. Cualquier cambio que surgiera posteriormente, debía ser estudiado, y ver si implicaba un coste adicional o podía asumirse dentro del proyecto.

Ahora que trabajo en una "empresa final", es decir, que desarrollamos para nosotros mismos, las cosas cambian. Puedes realizar igualmente el análisis de requerimientos, y funcional, pero es difícil que las personas no técnicas de tu propia empresa se tomen el tiempo requerido para revisarlo detalladamente y validarlo. ¿Por qué? ... pues porque los cambios que se realicen posteriormente no les cuestan dinero, solamente tiempo. Puedes decir que el tiempo es dinero, y tienes razón, pero mientras no haya una correspondencia directa entre modificación y euros, eso se diluye.

Estos son los casos en los que estoy comprobando, que es valioso el desarrollo con prototipo. Hacer los análisis más ligeros (no quiero decir que desaparezcan), y comenzar a desarrollar antes, para tener pronto algo básico sobre lo que discutir. A esto que los "no técnicos" pueden "palpar", si que le prestarán atención, propondrán y validarán funcionalidades ... vamos, que el prototipo podrá evolucionar hasta alcanzar el producto deseado.

Con todo esto que quiero decir, ¿es mejor el enfoque clasico o el prototipado?. Pues como te habrás imaginado tu mismo, depende del marco del proyecto. Si tuviera que volver a desarrollar para un cliente, dificilmente optaría por el prototipo, porque el factor tiempo, es muy dificil de estimar.

Otros artículos relacionados:
Artículos de gestión
Artículos de desarrollo