Agile Modeling (am)
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Agile Modeling (am) as PDF for free.
More details
- Words: 2,788
- Pages: 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.
1. 2.
3.
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: Actores del proyecto: Proporcionan información sobre el negocio y ayudan a priorizar las necesidades. 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. 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/
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.
1. 2.
3.
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: Actores del proyecto: Proporcionan información sobre el negocio y ayudan a priorizar las necesidades. 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. 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/
