Está en la página 1de 23

Agile Modeling

(AM)

Felipe Ferrada
Universidad del Bio-Bio
Introducción
 Los modelos ágiles se pueden describir como aquellos
modelos que son lo suficientemente buenos, donde
cumplen con las siguientes características las cuales son:
Satisfacen un propósito, son inteligentes, son lo
suficientemente preciso, son lo suficientemente detallado,
aportan valor positivo y son lo mas simple posible.
 Para poder tener mas clara las ideas un modelo ágil es más
eficiente que los modelos tradicionales, un prototipo de
papel podría ser un modelo ágil, un dibujo de pizarra podría
ser un modelo ágil, un diagrama de Visio puede ser un
modelo ágil o un modelo de datos físicos podría ser un
modelo ágil. El tipo de modelo, o herramienta con la que se
creó en realidad no importa, lo importante es que el
modelo sólo sea lo suficientemente bueno para su máximo
provecho.
¿Qué es y que no es un AM?
 AM es una actitud, no un proceso prescriptivo.
 AM es un complemento a los métodos existentes,
no es una metodología completa.
 AM es una manera efectiva de trabajar en
conjunto para alcanzar las necesidades de las
partes interesadas en el proyecto.
 AM es algo que funciona en la práctica, no es una
teoría académica.
 AM es para el desarrollador promedio, no es para
la gente competente.
 AM no es un ataque a la documentación, de hecho
AM aconseja la creación de documentos que
tengan valor.
 AN no es para todos.
¿Qué es Agile Modeling?
 Se puede describir como una metodología basada en la
práctica para modelado efectivo de sistemas de software.
 AM no es un proceso prescriptivo, ni define procedimientos
detallados de como crear un tipo de modelo dado en lugar
de eso, sugiere prácticas para ser un modelador efectivo.
 El secreto de AM no son las técnicas de modelado, como
pueden ser los modelos de casos de uso, los modelos de
clases, modelos de datos o los modelos de interfaz para el
usuario, sino es como se aplican.
 AM se puede describir como algo sentimental es decir no
siguen ninguna secuencia de ideas y no como algo duro y
rápido. Los ingenieros enfocados en esta metodología
piensan en AM como un arte, no una ciencia.
 AM va enfocado a la realización eficiente del
modelado y documentación.
 AM no es un proceso de desarrollo de software
completo, donde no incluye las actividades de
programación, las actividades de prueba, no cubre
la gestión de proyectos, implementación del
sistema, las operaciones del sistema, soporte del
sistema u otros elementos relacionados con la
realización de proyectos que no sean la
documentación y el modelado.
 AM es necesario usarlo con otro proceso de
software como puede ser XP, DSDM, SCRUM o RUP.

 La metodología AM es una colección de prácticas,


guiadas por principios y valores que pueden ser
aplicados por profesionales de software
Valores de Agile Modeling (AM)
 Comunicación: Es un valor muy importante ya que promueve
una comunicación entre el equipo de trabajo y sus participantes
en el proyecto, así como entre los desarrolladores y analistas.
 Simplicidad: Es importante que los desarrolladores entiendan
que los modelos son fundamentales para la simplificación del
software y así puedan tener la capacidad de elaborar un diagrama
o dos en vez de escribir decenas o incluso cientos de líneas de
código.
 Coraje: El coraje es importante porque hay que tomar decisiones
importantes y ser capaces de cambiar de dirección cuando el
camino tomado para el desarrollo no es el correcto.
 Humildad: Los mejores desarrolladores deben tener la humildad
de reconocer que ellos no lo saben todo, que tanto sus
compañeros desarrolladores, los clientes y de hecho todos los
interesados en el proyecto tienen algo que añadir para la mejor
realización.
Principios básicos y
complementarios de AM.
Principios Básicos:
 Modelar con un propósito: El primer paso es identificar un propósito válido
para la creación de algún modelo o documento, el segundo paso es averiguar
hasta que punto de detalles desea la información y el tercer paso es saber
para quien va dirigido el modelo.
• Maximizar la inversión de las partes interesadas en el proyecto: Los
interesados en el proyecto invierten recursos, tiempo, dinero, para poder
desarrollar el software que satisfaga sus necesidades en donde se merecen
que los recursos sean invertido de la mejor manera posible.
• Viaje con poco equipaje: Cada artefacto que se cree, y luego decidir
mantenerlo, tendrá que mantenerse en el tiempo. Es decir que es mejor
mantener tres modelos que poder mantener siete, logrando con esto un
trabajo mas ágil, o sea es mejor viajar ligero.
• Múltiples modelos: Actualmente es necesario saber utilizar múltiples
modelos para desarrollar software, ya que cada modelo describe un solo
aspecto del software.
 Rápida Retroalimentación: La retroalimentación cumple un papel
importante de una rápida comunicación entre el cliente y los desarrolladores
del proyecto, a demás permite una rápida conexión para comprender los
requisitos, para analizarlos o para satisfacer las necesidades de los clientes.
 Asumir simplicidad: La solución más sencilla generalmente es la
mejor solución ante cualquier problema. Mantener los modelos lo mas
simple posible.
 Bienvenido al cambio: Realizar los modelos y documentos que sean
adaptables a los cambios ya que se sabe que los requisitos pueden
evolucionar o cambiar con el tiempo.
 Trabajo de calidad: Se tienen que desarrollar trabajos de calidad ya
que a nadie le gusta el trabajo descuidado.
 El software es el objetivo primario: El objetivo de desarrollo de
software es la producción de alta calidad del trabajo de software que
satisfaga las necesidades de los interesados en el proyecto de una
manera eficaz.

Principios Complementarios:
 El contenido es más importante que la representación: Cualquier
modelo puede ser representado de varias formas. El punto importante
es que se aprovechen bien los beneficios del modelado sin incurrir en
los costes de creación y mantenimiento de la documentación.
 Comunicación abierta y honesta: La gente tiene que ser libre y
saber que son libres, para que puedan ofrecer sugerencias. La
comunicación abierta y honesta permite a las personas tomar mejores
decisiones, porque la calidad de la información en que se basan es
mas precisa.
 Todos pueden aprender de los demás: Siempre hay una oportunidad
de aprender más y ampliar los conocimientos. El punto es que se trabaja
en empresas donde el cambio es una norma, donde hay que aprovechar
cada oportunidad para aprender nuevas formas de hacer las cosas a
través de la formación, la educación, la tutoría, la lectura y el trabajo en
equipo.
 Conozca sus modelos: Debido a que ahí varios modelos para aplicar lo
que se necesita saber cuales son los puntos fuertes y débiles para ser
eficaz su uso.
 Conozca sus herramientas: Conocer herramientas de software, tales
como herramientas para realizar diagramas, para realizar modelados,
para la creación de códigos. A demás tener conocimientos sobre las
herramientas que va a utilizar saber las características que posee, y
saber cuando utilizarlas.
 Trabajar con los instintos de las personas: A medida que se
adquiere experiencia en desarrollo de software los instintos están mejor
enfocados y si ahí algún presentimiento de que por ejemplo algún
requisito no tiene sentido, o que la arquitectura no va a satisfacer las
necesidades de construcción, o que alguna técnica de diseño es mejor
que el diseño B simplemente ahí que seguir los instintos. Pero ahí que
tener coraje y valor para asumir si se llegara a equivocar y tener algún
plan de reserva para poder remediarlo.
Practicas básicas y
complementarias de AM.
 Participación activa de todos aquellos que soportan el proyecto:
Se describe la necesidad de tener un lugar de acceso a los usuarios que
tienen la autoridad y capacidad para proporcionar información
relacionada con el sistema que se está construyendo.
 Modelo con otras personas: Se trata de una actividad de grupo, en el
que varias personas puedan trabajar juntos de manera eficaz, como es la
programación en parejas.
 Aplicar los artefactos correctos: Cada artefacto tiene sus propias
aplicaciones específicas. Lo difícil es saber las fortalezas y debilidades de
cada tipo de artefacto, para saber cuándo y cuándo no utilizarlas.
 Demuestro con códigos: Un modelo es una abstracción, que debe
reflejarse con precisión el aspecto que estamos construyendo, pero para
determinar si funciona o no se debe probar el modelo son su código.
 Utilice las herramientas más sencillas: La gran mayoría de los
modelos se pueden extraer en una pizarra digital, en papel o incluso la
parte de atrás de una servilleta. Esto funciona porque la mayoría de los
modelos son desechables, su verdadero valor proviene en solucionar un
problema, y una vez que el problema se resuelve el diagrama no ofrece
mucho valor.
 Modelo en pequeños incrementos: Es un desarrollo
incremental en la que la organización proporciona esfuerzos
pequeños que se liberan con el tiempo.
 Crear varios modelos en paralelo: En los métodos ágiles se
descubrió que el trabajo es mucho más productivo en varios
modelos al mismo tiempo que por si sólo.
 Crear contenido simple: Se debe mantener el contenido real
de los modelos, los requisitos, análisis, o diseño tan simple
como sea posible y al mismo tiempo cumplir con las
necesidades de los interesados en el proyecto.
 Mostrar los modelos públicamente: Se debe mostrar los
modelos al público a menudo en algo llamado muro de
modelado o un muro de la maravilla.

Prácticas complementarias
 Aplique los estándares de modelado: La idea básica es que
los desarrolladores deben aceptar y seguir un conjunto común
de normas sobre el modelado de un proyecto de software.
 Descartar los modelos temporales: La gran mayoría de los
modelos que se crean son temporales es decir modelos de
trabajo, dibujos de diseño, prototipos de baja fidelidad, tarjetas
de índice, alternativas de diseño, y así sucesivamente. Son
modelos que han cumplido su propósito y se tiene que tomar la
decisión de actualizarlos o simplemente eliminarlos.
 Actualice solo cuando duela: Se debe actualizar un modelo
sólo cuando sea absolutamente necesario.
 Modele para comunicar: Una de las razones es el modelo
para comunicarse con personas externas a su equipo de
trabajo o para crear un modelo de contrato.
 Modele para entender: La aplicación más importante de la
modelización es explorar el espacio del problema, identificar y
analizar los requisitos para el sistema, o comparar y encontrar
posibles alternativas de diseño para identificar la solución más
simple que cumpla con los requisitos.
 Reutilizar los recursos existentes: Hay una gran cantidad
de información que los modeladores ágiles pueden tomar
ventaja
Relación entre las practicas de
Agile Modeling (AM).
 El trabajo en equipo: Se divide en cuatro categorías las
cuales son participación activa de los interesados, modelar
con otras personas, mostrar los modelos a las empresas, y la
propiedad colectiva, esta etapa trata generalmente de la
recolección de requerimientos.
 Iterativo e incremental: Esta categoría incluya las prácticas
AM como son crear varios modelos en paralelo, modelo en
pequeños incrementos, aplicar los artefactos correctos. Esta
etapa funciona de la siguiente manera son iteraciones de ida
y vuelta entre artefactos, donde uno de ellos puede ser el
código del programa, se habilita la practica de modelo en
pequeños incrementos donde normalmente funciona de a
poco un artefacto luego otro, luego otro y así sucesivamente.
 Simplicidad: Esta categoría incluye las prácticas básicas de
crear contenido simple, presentar modelos públicamente y de
la forma mas simple posible, y utilizar herramientas lo mas
sencillas posible. Esta etapa describe generalmente las etapas
donde uno tiene que diseñar, modelar y documentar de la
forma mas simple posible y entendible para el usuario.
 Validación: Esta categoría consiste en la práctica central de
demostrar con el código. Ya que en la búsqueda activa de
probar un modelo con el código rápidamente se demuestra
que el sistema funciona.
Estructura de una sesión de
modelado
Una sesión de modelado es una actividad de una o más personas que se
centran en el desarrollo de uno o más modelos. Las sesiones del
modelaje son una parte importante en cualquier proyecto de
desarrollo de software, ya que proporcionan una oportunidad para la
colaboración colectiva con las personas que quieran comunicar sus
necesidades, para llegar a una mejor comprensión y tratar de
encontrar una solución.
Una sesión de modelado se puede componer de:
 Duración: Las sesiones de modelado a menudo van desde varios
minutos hasta varios días, donde una sesión tiene una duración de
diez a treinta minutos. Entre mayor tiempo tome la sesiones de
modelado mayor riesgo tiene el proyecto ya que cuanto más tiempo
pase sin reacción mayor es la probabilidad de que lo que está
modelando no refleje lo que realmente sea. Los desarrolladores
ágiles realizan sesiones cortas de modelado, es decir que cuando se
trabaja en trozos pequeños y de forma iterativa se descubre que las
sesiones de modelado corto son suficientes.
 Tipos de sesiones de modelado: Unos de los problemas es
que cuando se toman sesiones de modelado uno siempre
quiere tratar de realizar todo tipo de modelos en una sola
sesión es decir realizar modelos de datos, modelos de casos
de uso, e incluso modelo de clases. AM describe que es mejor
mantener sesiones de modelado ágil, es decir que es mejor
tener varias sesiones de modelado y de tiempo pequeño
donde el grupo de modelado estará enfocado en realizar un
solo tipo de modelo en cada sesión que tratar de realizar
todos los modelos en una sola sesión.
 Participantes: Hay dos categorías de funciones en el
modelado de las sesiones, los cuales son los participantes
activos y el apoyo a los participantes. La categoría
participantes activo contiene tres funciones básicas:
1. Actores del proyecto: Proporcionan información sobre el
negocio y ayudan a priorizar las necesidades.
2. Los analistas: Los cuales están especializados en el trabajo
directo, son los interesados del proyecto, donde tienen la
misión de reunir información.
3. Los desarrolladores: Los cuales están para trabajar en los
modelos.
La categoría de los participantes de apoyo consta de tres roles
los cuales son:
1. Facilitador: Un facilitador es alguien que es responsable de
la planificación, ejecución y gestión de sesiones de
modelaje. Lo facilitadores tienen buenas habilidades, como
comprender el proceso de modelado, donde realizan
preguntas validas e inteligentes para obtener información
de los participantes activos.
2. Escriba: Un escribano es una persona responsable de la
recogida de información durante la sesión de modelado.
Estos tienen que tener una buena habilidad para escuchar y
una buena capacidad de comunicación oral.
3. Observador: Tradicionalmente un observador es alguien
que no está para participar en una sesión de modelado, es
decir solamente entra a la sesión se sienta y ve lo que
ocurre de modo que pueda aprender el proceso. El objetivo
del observador es aprender el proceso, y la mejor manera
de aprender las cosas es participando en las sesiones. En
AM los observadores pueden actuar como modeladores o
escritores o incluso participantes activos.
Documentación en Agile
Modeling (AM)
La documentación es algo muy importante en este
tipo de metodología, un documento es ágil cuando
cumple los siguientes criterios:
 El beneficio proporcionado por un documento ágil es
mayor que la inversión en su creación y el
mantenimiento
 Las partes interesadas deben comprender el costo
total del documento y estar dispuesto a invertir en
la creación y mantenimiento de dicho documento.
 Un documento ágil contiene información suficiente
para cumplir su propósito, en otras palabras, es tan
sencillo como puede ser.
 Los documentos ágiles tienen que ser coherentes y
cumplir un propósito, donde se tiene que saber el
propósito antes de diseñar el documento.
 Los documentos ágiles tienen un cliente
determinado y facilitan los esfuerzos de trabajo de
ese cliente, como por ejemplo la documentación de
usuario a menudo incluye tutoriales para el uso del
sistema el cual tiene que ser escrito en el lenguaje
que los usuarios puedan entender.
 Se debe trabajar estrechamente con el cliente para
poder crear la documentación necesaria para que
pueda satisfacer sus necesidades. Cuando se tiene
que los clientes no participan activamente en el
proyecto se tiene mucha creación de
documentación innecesaria donde a veces puede
ser mucha documentación y esto produce que sea
cada vez menos ágil.
 Los documentos ágiles no necesitan ser prefectos
solo tienen que ser lo suficientemente buenos.
Conclusión
 Agile Modeling (AM) se puede decir que es
una metodología muy practica a la hora de
tener que diseñar modelados y
documentación, ya que proporciona
información de cómo poder realizarlos de
una manera ágil, logrando entregar
modelos y documentos que realmente
sean de importancia para el usuario y
eliminando los datos que sean
innecesarios.
Bibliografía
 http://www.agilemodeling.com/