Y aunque algunos de ellos son muy jóvenes y están aún en pleno arranque, no está de más echar a un vistazo a la evolución, no siempre lineal en el tiempo:
Database Driven Design (¿DDD?).
Es el diseño de una aplicación partiendo del modelo de datos. Durante muchos años explicado en las universidades y otros centros de enseñanza, al final es más una consecuencia de la forma de pensar que de una necesidad de arquitectura o diseño. La necesidad de establecer un modelo de datos como "base" en las fases más tempranas, conlleva que tratemos de definir al máximo los datos, su estructura y flujo. Al final, las pantallas no dejan de ser un mero reflejo de dicho modelo. Por desgracia, esta forma de trabajo con el tipo de aplicaciones actuales orientadas al usuario, donde la interfaz es el rey, y lo importante es hacer sentir cómodo al usuario.
He sido fan de este modelo de diseño, pero ha chocado con una realidad, y es que es relativamente sencillo definir un modelo de datos y una capa de negocio que cumplan con los objetivos. Sin embargo, las interfaces de usuario se resisten, en especial con la explosión del mundo web, que ha acabado barriendo los desarrollos de escritorio (en orden de magnitud). Ha tenido que llegar el año 2010/2011 para que tengamos que oir (otra vez) la promesa de que con nuevos estándares (esta vez HTML5 entre otros), la web será "como las aplicaciones de escritorio". Gracias por reinventar la rueda, pero seguiremos esperando. Mientras tanto, las aplicaciones (de escritorio o web), siguen fallando de forma habitual en la interfaz.
Interaction Design (Goal-Oriented Design=GOD)
Similar a la anterior, está apadrinada (entre otros) por Alan Cooper, experto en temas de interacción y usabilidad (os recomiendo su famoso "The Inmates are Running The Asylum", donde trata la metodología "Goal-Oriented Design"). Bajo mi punto de vista, es una metodología desaprovechada, y que sigue cubriendo aquello que muchas otras metodologías están buscando abordar: la satisfacción del usuario.
Test Driven Development (TDD)
Esta vez sin seguir secuencia cronológica, la TDD o metodología de desarrollo guiada por pruebas, nos invita a acelerar los desarrollos y mejorar la calidad de los productos, basándose esta vez en otra de las fases o actividades del ciclo de vida: las pruebas. De nuevo, una gran promesa, todavía sin caer en el desprecio, pero que exige por parte de los equipos de desarrollo de dos ingredientes no habituales: disciplina y mesura. Disciplina para crear con antelación los tests, y mesura para saber hasta dónde llegar con las pruebas.
Domain Driven Design (DDD)
Según el sitio web http://domaindrivendesign.org es una forma de pensar, en lugar de una metodología. Dejando aparte dogmatismos insondables, se centran en la parte del diseño de un modelo, de la capa de negocio principalmente. De esta forma, se pretende dar solución a los proyectos en los que la complejidad y el tamaño del software a construir haga inabordable la tarea. Bajo mi punto de vista, esta forma de trabajo, sigue adoleciendo de problemas similares a los que presentan otras técnicas. De hecho, si una de las causas del fracaso del software es la complejidad del software, tenemos un grave problema no metodológico, sino de análisis y de visión del producto.
[Editado]: ¡me había dejado Feature Driven Development!
Feature Driven Development (FDD)
Es una metodología de desarrollo ágil, centrada en el modelo, y en la que el desarrollo está liderado por los requisitos. Es una metodología que parece encajar muy bien en equipos y proyectos grandes. Ya le dedicaré un post con más tranquilidad otro día.
No hay comentarios:
Publicar un comentario