Modelado Agil

Modelado Ágil es una metodología basada en la práctica para el modelado y eficaz documentación de los sistemas basados ​​en software. En un Modelado Ágil de alto nivel es una colección de las mejores prácticas, representados en el mapa de lenguaje de patrones. A un nivel más detallado Modelado Ágil es una colección de valores, principios y prácticas para el software de modelado que se pueden aplicar en un proyecto de desarrollo de software de una manera eficaz y ligero.

El Modelado Ágil (AM) fue propuesto por Scott Ambler no tanto como una metodología ágil cerrada en sí misma, sino como complemento de otras metodologías, sean éstas ágiles o convencionales. AM no es proceso completo ni una metodología ágil, sino un conjunto de principios y prácticas para modelar y realizar el análisis de requisitos, complementando a la mayoría de las metodologías iterativas. Ambler recomienda su uso con XP, RUP o cualquier otra metodología. En el caso de XP los practicantes podrían definir mejor los procesos de modelado que en ellos faltan, y en el caso de RUP, el modelado ágil permite hacer más ligeros los procesos que ya usan.

Objetivos y  Valores:

Los principales objetivos de AM son:

·         Definir y mostrar de qué manera se deben poner en práctica una colección de valores, principios y prácticas que conducen al modelado ligero.

·         Describir cómo aplicar las técnicas de modelado en equipos que desarrollan software mediante un enfoque ágil.

·         Describir cómo mejorar las actividades de modelado mediante un enfoque "casi-ágil", en particular, en proyectos que sigan una metodología similar a RUP.

Los valores de AM incluyen a los de XP: comunicación, simplicidad, feedback y coraje, añadiendo humildad. La humildad porque hemos de admitir que quizás no lo sepamos todo, que el resto de los compañeros tienen cosas que aportar a los proyectos.

Un modelo es ágil si:

·         Cumple con su propósito, ya sea para comunicar o para comprender.

·         Es comprensible por la audiencia a la que van dirigidos. Un modelo valido para el equipo de desarrollo no nos va a servir para mostrarlo a los usuarios.

·         Es suficientemente preciso. Lo normal es no necesitar el 100% de precisión en un modelo.

·         Es suficientemente consistente. Nos podemos permitir nombrar al mismo elemento de forma diferente en 2 modelos distintos (contraseña y password), siempre y cuando quede claro que es el mismo objeto.

·         Esta suficientemente detallado, dependiendo de la audiencia y del proyecto.

·         Aporta valor positivo. Es decir, es un modelo que vale la pena realizar, y que no conlleva más esfuerzos que lo que llega a aportar. No lo hacemos por obligación.

·         Es tan simple como sea posible. Siempre hemos de tener el principio KISS en mente.