METODOLOGÍAS EMERGENTES

Preámbulo al tema.

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software.

Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas.

Según el Manifiesto se valora:

AL INDIVIDUO Y LAS INTERACCIONES DEL EQUIPO DE DESARROLLO SOBRE EL PROCESO Y LAS HERRAMIENTAS. La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.

DESARROLLAR SOFTWARE QUE FUNCIONA MÁS QUE CONSEGUIR UNA BUENA DOCUMENTACIÓN. La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.

LA COLABORACIÓN CON EL CLIENTE MÁS QUE LA NEGOCIACIÓN DE UN CONTRATO. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

RESPONDER A LOS CAMBIOS MÁS QUE SEGUIR ESTRICTAMENTE UN PLAN. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Los dos primeros principios son generales y resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organización del mismo. Los principios son:

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.

III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.

Cada metodología tiene características propias y hace hincapié en algunos aspectos más específicos. A continuación se resumen otras metodologías ágiles. La mayoría de ellas ya estaban siendo utilizadas con éxito en proyectos reales pero les faltaba una mayor difusión y reconocimiento.

SCRUM.

Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyecto s con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos.

I. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente.

II. las reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.

Es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

También se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

Beneficios

Los principales beneficios que proporciona Scrum son:

Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese momento, ya completados) lo cual proporciona las siguientes ventajas:

Gestión regular de las expectativas del cliente y basada en resultados tangibles. Resultados anticipados (time to market). Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el

mercado, etc. Gestión sistemática del Retorno de Inversión (ROI). Mitigación sistemática de los riesgos del proyecto.

Productividad y calidad. Alineamiento entre el cliente y el equipo de desarrollo. Equipo motivado.

Cómo funcionaEn Scrum un proyecto se ejecuta en bloques temporales cortos y fijos  (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversión mediante la re planificación de objetivos que realiza al inicio de cada iteración.

 

Planificación de la iteración 

El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes:

1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.

2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se auto asignan las tareas. 

Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas:

¿Qué he hecho desde la última reunión de sincronización? ¿Qué voy a hacer a partir de este momento? ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.

 Elimina los obstáculos que el equipo no puede resolver por sí mismo.

Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto.

2.  Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.

MODEL DRIVEN ARCHITECTURE

En los últimos meses muchas organizaciones han empezado a centrar la atención en Model Driven Architecture (MDA) como una aproximación al diseño e implementación de aplicaciones. Este es un hecho muy positivo por varias razones. MDA fomenta el uso eficiente de los modelos de sistemas en el proceso de desarrollo de software, y es compatible con la reutilización de las mejores prácticas al crear familias de sistemas. Tal como se define por el Object Management Group (OMG), MDA es una forma de organizar y gestionar arquitecturas empresariales apoyadas por herramientas y servicios automatizados, tanto para la definición de los modelos y facilitar transformaciones entre diferentes tipos de modelos.

Si bien las normas de MDA definidos OMG y terminología para la creación y evolución de los sistemas de software a escala de empresa se están ampliamente referenciados en la industria, sólo recientemente la OMG y sus miembros, incluyendo IBM Rational, ha sido capaz de ofrecer una orientación clara sobre lo que significa la MDA, donde nos encontramos en su evolución, ¿qué aspectos de la MDA son posibles con la tecnología actual, y cómo tomar ventaja de la MDA en la práctica.

El concepto de MDA del OMG proporciona un enfoque abierto y neutral a la interoperabilidad del sistema a través de estándares de modelado establecidos de OMG: Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), y Common Almacén Meta-modelo (CWM). Las descripciones de las soluciones empresariales pueden ser construidas usando estos estándares de modelado y se transforma en una plataforma abierta o propietaria importante, incluyendo CORBA, J2EE, .NET y plataformas basadas en la Web.

Antes de profundizar más en MDA, vamos a considerar los conceptos fundamentales y los beneficios del modelado en desarrollo de software.

LA JUSTIFICACIÓN PARA EL MODELADO

Los modelos proporcionan abstracciones de un sistema físico que permiten a los ingenieros de razonar acerca de ese sistema, ignorando detalles superfluos mientras se centra en los relevantes. Todas las formas de ingeniería se basan en modelos para entender los sistemas complejos, en el mundo real. Los modelos se utilizan de muchas maneras: para predecir las cualidades del sistema, razón acerca de las propiedades específicas cuando se cambian los aspectos del sistema, y comunicar las características clave del sistema para las distintas partes interesadas. Los modelos pueden ser desarrollados como un precursor de la aplicación del sistema físico, o pueden ser derivados de un sistema existente o un sistema en el desarrollo como una ayuda para la comprensión de su comportamiento.

PUNTOS DE VISTA Y LA TRANSFORMACIÓN DEL MODELO

Debido a que muchos aspectos de un sistema pueden ser de su interés, puede utilizar varios conceptos de modelado y anotaciones para resaltar una o más perspectivas particulares, o puntos de vista, de ese sistema, dependiendo de lo que es relevante en cualquier punto en el tiempo. Por otra parte, en algunos casos, puede aumentar los modelos con indirectas, o reglas, que ayudan a transformarlos de una representación a otra. A menudo es necesario convertir a diferentes vistas del sistema a un nivel equivalente de abstracción (por ejemplo, a partir de una vista estructural de una vista de comportamiento), y una transformación de modelos facilita esto. En otros casos, una transformación convierte los modelos que ofrecen una perspectiva particular de un nivel de abstracción a otro, por lo general a partir de un punto de vista más abstracto a menos abstracto, añadiendo más detalle suministrado por las reglas de transformación.

MODELOS, MODELADO, Y MDA

Modelos y dirigido por el modelo de desarrollo de software están en el corazón del enfoque MDA. Así que para entender mejor la MDA, es conveniente primer vistazo a cómo los desarrolladores de aplicaciones empresariales se aprovechan de modelado.

En el mundo de la ingeniería de software, modelado tiene una rica tradición, que se remonta a los primeros días de programación. Las innovaciones más recientes se han centrado en las notaciones y herramientas que permiten a los usuarios a expresar puntos de vista del sistema de valor a los arquitectos y desarrolladores de software de manera que se asignan fácilmente en el código de lenguaje de programación que puede ser compilado para una plataforma de sistema operativo en particular. El estado actual de esta práctica emplea el Unified Modeling Language (UML) como la notación de modelado primario. El UML permite a los equipos de desarrollo para capturar una variedad de características importantes de un sistema en los modelos correspondientes. Transformaciones entre estos modelos son principalmente manuales.

Herramientas de modelado UML suelen apoyar las relaciones requisitos de trazabilidad y de dependencia entre los elementos de modelado, con los justificantes y ofertas de consultoría complementarios orientados a la guía de mejores prácticas sobre cómo mantener sincronizados los modelos como parte de un esfuerzo de desarrollo a gran escala.

Una forma útil para caracterizar la práctica actual es mirar a las diferentes formas en que los modelos están sincronizados con el código fuente que ayudan a describir. que muestra el espectro de métodos de modelización en uso por los profesionales de software hoy en día. Cada categoría identifica un uso particular de los modelos en la asistencia a los profesionales de software para crear aplicaciones en ejecución (código) para una plataforma de ejecución específica, y la relación entre los modelos y el código.

LOS PRINCIPIOS DE MDA

Modelado ha tenido un impacto importante en la ingeniería de software, y es fundamental para el éxito de todas las soluciones a escala empresarial. Sin embargo, hay una gran variedad en lo que los modelos representan y cómo se utilizan. Una pregunta interesante es: ¿cuál de estos enfoques podemos describir como "modelo-driven"? Si se crea una visualización de una parte de un sistema, ¿significa que estoy practicando MDA? Desafortunadamente, no hay una respuesta definitiva. Por el contrario, existe un consenso creciente de que la MDA está más estrechamente asociado con enfoques en los que el código es (semi) generada automáticamente a partir de los modelos más abstractos, y que emplean lenguajes de especificación estándar para la descripción de esos modelos.

Hay cuatro principios subyacentes de la vista de OMG de MDA:

1. Modelos expresados en una notación bien definida son una piedra angular para la comprensión de sistemas para soluciones de escala empresarial.

2. La construcción de sistemas puede ser organizada en torno a un conjunto de modelos mediante la imposición de una serie de transformaciones entre modelos, organizados en un marco arquitectónico de capas y transformaciones.

3. Un respaldo formal para describir los modelos en un conjunto de metamodelos facilita la integración y transformación significativa entre los modelos, y es la base para la automatización a través de herramientas.

4. La aceptación y la amplia adopción de este enfoque basado en el modelo requiere de estándares de la industria para proporcionar la apertura a los consumidores, y fomentar la competencia entre los proveedores.

Para apoyar estos principios, la OMG ha definido un conjunto específico de capas y transformaciones que proporcionan un marco conceptual y el vocabulario para la MDA. En particular, OMG identifica cuatro tipos de modelos: Computación Independiente Model (CIM), Plataforma Modelo Independiente (PIM), Plataforma modelo específico (PSM) descritos por un modelo de plataforma (PM), y un modelo específico de implementación (ISM).

Para MDA, una "plataforma" sólo tiene sentido en relación con un punto de vista particular - en otras palabras, PIM de una persona es PSM de otra persona. Por ejemplo, un modelo puede ser un PIM con respecto a la elección de middleware de comunicación si ese modelo no prescribe una elección particular de la tecnología middleware. Sin embargo, cuando se toma la decisión de usar particular, middleware tales como CORBA, el modelo se transforma en un PSM-CORBA específico.

Tres ideas son importantes aquí con respecto a la naturaleza abstracta de un modelo y la aplicación detallada que representa:

Modelo de clasificación. Podemos clasificar los modelos de software y del sistema en términos de cómo de manera explícita que representan aspectos de las plataformas como objetivo. En todo el desarrollo de software y el sistema existen limitaciones importantes que implica la selección de idiomas, el hardware, la topología de red, protocolos de comunicación y la infraestructura, y así sucesivamente. Cada uno de estos se pueden considerar elementos de una solución "plataforma". Un enfoque MDA nos ayuda a centrarse en lo que es esencial para los aspectos del negocio de una solución que está siendo diseñado, separado de los detalles de esa "plataforma".

Independencia de la plataforma.

La noción de una "plataforma" es bastante complejo y altamente dependiente del contexto. Por ejemplo, en algunas situaciones, la plataforma puede ser el sistema operativo y utilidades asociadas; en algunas situaciones puede ser una infraestructura de tecnología representada por un modelo de programación bien definido como J2EE o .Net; en otras situaciones, es un caso particular de una topología de hardware. En cualquier caso, es más importante pensar en términos de lo que los modelos a diferentes niveles de abstracción se utilizan para diferentes propósitos qué, en lugar de ser distraído con la definición de la "plataforma".

Transformación de modelos y refinamiento.

Al pensar en el desarrollo de software y sistema como un conjunto de refinamientos modelo, las transformaciones entre modelos se convierten en elementos de primer nivel del proceso de desarrollo. Esto es importante debido a que una gran cantidad de trabajo tiene lugar en la definición de estas transformaciones, a menudo requieren un conocimiento especializado del dominio de negocio, las tecnologías que están siendo utilizados para la ejecución, o ambos. Podemos mejorar la eficiencia y la calidad de los sistemas mediante la captura de estas transformaciones de forma explícita y de volver a utilizar constantemente a través de soluciones. Si están bien definidos los diferentes modelos abstractos, podemos utilizar transformaciones estándar. Por ejemplo, entre los modelos de diseño expresados en UML e implementaciones en J2EE, podemos, en muchos

casos, utilizar patrones de transformación de UML a J2EE bien entendidos que pueden ser aplicadas consistentemente, validados y automatizados.

Bibliografía

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Rational+Team+Concert+for+Scrum+Projects/page/SCRUM+como+metodolog%C3%ADa,http://www.ibm.com/developerworks/rational/library/content/RationalEdge/apr05/brown/

Metodologías Ágiles en elDesarrollo de SoftwareAlicante, 12 de Noviembre de 2003

Taller realizado en el marco de las VIII Jornadas de Ingeniería delSoftware y Bases de Datos, JISBD 2003.Alicante, del 12 al 14 de Noviembre de 2003