Agilismo: Brecha y Consecuencias

En comparaciones entre la arquitectura de software y el desarrollo con metodologías ágiles, usualmente de indica que existen una serie de dicotomías entre ambos (Ref #1). Mientras que el trabajo arquitectural en el desarrollo se orienta a trabajar con abstracciones aún mayores a las que se usan en la Ingeniería de Software en el modelado y diseño de sistemas (Ref #35), las metodologías de desarrollo llamadas ágiles ven poco valor en el diseño previo y sus validaciones y proponen enfocarse más en trabajo generador de producto utilizable, como la codificación, según se entiende en el Manifiesto Ágil (Ref #1 y #6).

Las metodologías desarrollo llamadas ágiles ven poco valor en el diseño previo y sus validaciones y proponen enfocarse más en trabajo generador de producto utilizable

La documentación es una de esas dicotomías. La arquitectura es erróneamente considerada una actividad de diseño exhaustivo previo, que genera masivas cantidades de documentación que puede luego no usarse (Ref #10). A pesar de que la documentación no está completamente vedada en las metodologías ágiles (Ref #19), la generación de documentación masiva que luego no es utilizada, sí es algo que dichas metodologías rechazan. Las metodologías ágiles buscan generar documentación bajo demanda, en el momento necesitado y si es necesaria (Ref #18).

Sin embargo, la información documentable en el trabajo a nivel arquitectural va más allá del diseño previo. La información arquitectural incluye también las decisiones tomadas y el razonamiento que ha llevado a éstas (Ref #4). Dicha información es conocida como Conocimiento Arquitectural. Se han realizado varios estudios sobre la importancia de dicho conocimiento (Ref #31 y #4) y se han propuesto modelos para capturar y administrar dicha información (Ref #8), aunque su uso práctico aún no esté tan desarrollado (Ref #4).

Este artículo pretende identificar las posibles consecuencias de la brecha que existe entre la tarea de documentación minimalista y bajo demanda que impulsa el movimiento ágil y el trabajo de documentación de modelos, decisiones y razonamiento que se propone usar en arquitectura de software. Este es un primer trabajo de identificación del problema, sin llegar a ahondar en su definición formal o en las soluciones al mismo.

Breve Repaso

El término arquitectura de software fue inicialmente mencionado en las conferencias de la OTAN, 1969 y 1970 (Ref #26), como un trabajo con un nivel de abstracción superior al de Ingeniería de Software. El término arquitectura se dio inicialmente siguiendo una analogía a las ciencias de la construcción de edificios. La definición del concepto ha ido evolucionando a los largo de 40 años con trabajos como los de Perry y Wolf (Ref #25) y con particular fuerza académica, el trabajo del SEI de la Carnegie Mellon (Garlan, y otros, 2010) (Ref #5). El trabajo arquitectural requiere la toma de decisiones de alto nivel, sobre la estructura del sistema, sus componentes, las interrelaciones de ellos y las características externamente visibles (Ref #35).

La arquitectura de software trabaja las descripciones de las soluciones o sistemas a muy alto nivel, pero a pesar de eso dicha descripción aún puede ser muy complicada para ser representada en un solo modelo. (Ref #35). Es por eso que se ha constituido un conjunto de buenas prácticas y conceptos estándar para la descripción de la arquitectura de un sistema, originalmente por la IEEE (IEEE 1471:2000) (Ref #23) que luego evolucionó a ISO/IEC/IEEE 42010 (ISO/IEEE, 2011). Con esto se definió que la descripción de una arquitectura se haría utilizando “vistas” basadas en “Puntos de Vista” (que son como manuales para crear vistas), que se enfocan en una parte del sistema (una vista puede describir las funciones que realiza el sistema y otra el modelo de información) (Ref #35). Este concepto se derivó del trabajo de Parnas en los 70s y de Perry y Wolf en los 90s, pero se aceptó de forma general con el trabajo descriptivo de Krutchen (Ref #20).

Por otro lado, a finales del siglo XX, la industria de software estaba siguiendo el modelo “cascada” descrito por el Doctor Winston W. Royce (Ref #27) (que era de hecho un contraejemplo que no se debía seguir), que implicaba un ciclo de desarrollo por fases independientes y consecutivas. Las primeras fases se dedicaban a recolectar los requerimientos o casos de uso del sistema por construir y diseñar una solución, todo previo a la construcción misma. Como los estimados del esfuerzo de construcción del software se basaban en los requerimientos y el diseño, estas fases tendían a ser exhaustivas en la práctica. Toda la información era documentada (requerimientos y diseño) generando documentación previa, particularmente para sistema muy grandes. A esto se le conoció como “Gran Diseño Previo”) (Big Design Up Front). En el 2001, un grupo de 17 representantes de nuevas metodologías de desarrollo se reunieron en Utah, Estados Unidos, para discutir y firmar un manifiesto que incluye los principios para metodologías de desarrollo que fueran más orientadas a dar valor y a reducir el esfuerzo siguiendo un desarrollo iterativo, en contraposición al modelo de cascada. A ese documento se le llamó el Manifiesto Ágil, y a los firmantes se les conoce como La Alianza Ágil. Uno de esos principios indica que hay que darle más valor “al software funcionando que a la documentación comprehensiva” (Beck, y otros, 2011). Por tal razón las metodologías que siguen los principios ágiles tienden a eliminar o reducir al mínimo la documentación y generarla en el momento que se requiera durante las iteraciones, no de previo.

Como respuesta a este pensamiento llamado agilista, por parte de los que trabajan con arquitectura de software, han salido algunas propuestas de trabajo arquitectural adaptado a las iteraciones (Ref #2 y #3) o minimizando el trabajo previo y retardando decisiones para etapas posteriores basados en criterios como los riesgos y los cambios de requerimientos (Ref #12) . Sin embargo, en términos de documentación, la mayoría del esfuerzo se centra en la descripción arquitectural sugerida en IEEE 1471/ISO 42010 (Ref #23), basado en el concepto de “Vistas arquitecturales”, las decisiones y el razonamiento (Avgeriou, Kruchten, Lago, Grisham, & Perry, 2007). Más allá de la captura, es el control y aprovechamiento de dicha información lo que es tomado como muy importante, pero muy difícil de concretar dados los problemas de falta de tiempo, presupuesto y herramientas (Ref #31). Varias herramientas han sido propuestas y comparadas (Ref #30) pero solo han logrado obtener resultados en la captura de la información, no así en su localización (búsqueda comprehensiva) y consumo (lectura y utilización) (Ref #4).

Para las metodologías ágiles, los documentos se crean en procesadores de palabras o presentaciones (Ref #31). También está el uso de wikis (Ref #22). En tales casos se presentan problemas de control, de evaluación de uso, de continuidad y mantenimiento. La información arquitectural es usualmente catalogada como “estratégica” mientras que la poca información registrada con metodologías ágiles es del tipo operativo (más cercana a las decisiones de codificación y diseño táctico).

Finalmente, hay propuestas para generar documentación arquitectural ágil, particularmente por parte del SEI (Ref #9), que intenta acoplar las vistas y los conceptos del ISO a las iteraciones ágiles.

Veamos entonces cuál es el problema presentado por las soluciones de administración de conocimiento arquitectural y las propuestas ágiles.

El Problema del Qué y el Para Qué de la Documentación

La problemática de la documentación arquitectural ya ha sido tratada en muchos lugares y de diversas formas (Garlan, y otros, 2010), siendo las basadas en las buenas prácticas de la IEEE/ISO las más comunes. Más allá de una descripción de diseño de algo por crear, la descripción arquitectural es algo vivo que incluye las decisiones tomadas y el raciocinio detrás de dichas decisiones, lo que ha sido llamado Conocimiento Arquitectural (Architectural Knowledge, identificada en este trabajo como “AK”). Existen muchas herramientas que han sido creadas para administrar tal conocimiento (Captura, localización y consumo) (Ref #4) que revisaremos luego, pero como se indica en (Ref #4), la investigación se ha enfocado en la captura (qué capturar y cómo) , mientras que ha dejado aún abierto el problema de localización (consultas y búsquedas) y del consumo de dicha información. El uso de tales herramientas no ha sido tan difundido (Ref #35). Esto significa que es muy fácil generar documentación, pero no tan fácil el consumirla.

En el caso de los desarrollos con metodologías Ágiles, el día a día sigue siendo documentos Word y Wikis con información escueta orientada a la codificación, de tipo operativa. Esta información es capturada al momento de ser producida y no de forma previa. Sobre este respecto ha información empírica y algunos manuales de buenas prácticas que sugieren un proceso documentativo, pero muy pocos estudios de campo que brinden más información.

Existe entonces un conjunto de herramientas que está capturando AK y que tiene algunas características de búsqueda y consumo de la información, en general pobres, pero que por causas del diseño y del tipo de información (estratégica) no son utilizadas de forma importante en el mundo ágil (más detalle sobre AK y sus procesos más adelante). Existe por tanto una brecha y una barrera de aceptación que puede resumirse en:

1. La información de la AK y la información que se maneja en el agilismo están a niveles diferentes (estrategia vrs operación).
2. Hay un rechazo a la actividad de documentación de parte del agilismo, basado en el principio de preferir código funcional antes que documentación comprehensiva. La premisa es que la documentación requiere tiempo para generar un producto no utilizado.
3. Las herramientas actuales de captura y administración de la AK tienen una tendencia a la documentación a través del modelado, durante fase de diseño, con enfoque en la captura pero pobres para el consumo, que no es aceptada como útil en el agilismo (el diseño debe ser emergente y no previo). Por tanto, tienen poca oportunidad de ser usadas por el agilismo.

¿Es importante la AK para el Agilismo?

Los modelos de documentación y herramientas actuales están muy orientados al modelado de la solución o diseño, tarea que es usualmente realizada de previo. La información capturada durante el proceso puede ser soportada por dichas herramientas pero usualmente este análisis del proceso puede interferir en el mismo (Ref #4). La importancia de contar con una administración de la información arquitectural ya ha sido estudiada (Ref #31) y la conclusión es que para el proceso de desarrollo sí es importante. A pesar de esto, aún no se ha logrado la aceptación de las herramientas creadas por el hecho ya mencionado de que estas tienen deficiencias para la localización y consumo, particularmente porque no se tiene un claro conocimiento de la forma natural con la que los desarrolladores y otros roles buscan y consumen la información (Ref #4).

Es por eso que un análisis comparativo entre los requerimientos de las metodologías ágiles (que fomentan sólo la documentación necesaria y oportuna) y la solución ofrecida para administración de información arquitectural, puede dar una luz sobre los dos puntos abiertos hasta ahora: localización y consumo. Es decir, un estudio que analice la brecha entre los requerimientos y las soluciones actuales deberá ser enfocado en el área pendiente para la AK, que es cómo consumir dicha información.

La tarea no es sencilla, dado que las metodologías ágiles, al utilizar herramientas poco restrictivas en formato como los wikis y documentos Word, carecen en la mayoría de los casos de modelos o estructuras de información que puedan ser comparados. Por otro lado, esta situación puede ser una oportunidad para crear dichas estructuras y modelos. El estudio del conocimiento arquitectural tiene importantes avances en la definición de estructuras de información que pueden ser utilizadas.

Sin embargo, el crear dicho modelo implica otros retos igual de importantes. La información de conocimiento arquitectural es usualmente de nivel estratégico mientras que la capturada en wikis es más que todo operacional. Hay que diseñar mapas que permitan trazar información entre niveles y que a la vez brindan información útil a los diferentes roles del desarrollo. Por último, dicho modelo debe implicar un esfuerzo balanceado entre generar información (el costo) y consumirla (el beneficio), para lograr aceptación de las metodologías ágiles. Es por eso que se requieren pruebas de campo para validar los supuestos y detectar opciones de mejora en el modelo.

El estudio y la consecuente propuesta de un modelo documental, traería los siguientes beneficios:

1. Un entendimiento de las necesidades documentales del movimiento ágil, basados en sus principios y sus necesidades de comunicación.
2. Aceptación y uso de modelos de información de alto nivel (arquitecturales) en el proceso de desarrollo continuo incremental en contraposición al modelo de documentación previa.
3. Generación de criterios de evaluación de los modelos y la información utilizada en el desarrollo, bajo el enfoque agilista de oportunidad y utilidad.
4. Mejora en el proceso de desarrollo agilista para grandes proyectos, con múltiples equipos pequeños trabajando en sistemas grandes donde la información sea difícil de diseminar cara a cara.
5. Una estructura coherente y útil de la información en contraposición a la estructura ad hoc utilizada actualmente por el agilismo, que brinde mejoras en captura, localización y consumo.

Arquitectura de Software y Conocimiento Arquitectural

Concepto e Historia

El término Arquitectura relacionado al desarrollo de software fue por primera vez acuñado por Sharp, en las conferencias de la NATO, particularmente la registrada en 1970 (Buxton & Randell, 1969). P.I. Sharp menciona en ese entonces, en una discusión acerca del problema de la brecha de comunicación y sus consecuencias para el desarrollo de software y la ingeniería de software, que existe algo más allá que simplemente indicar lo que el programa hace. Menciona que debe definirse una “forma”, relacionando esto al diseño. En su comentario, analiza el caso del SO/360, que tiene sus partes muy bien codificadas, pero como fueron asignadas a grupos de ingenieros por separado, al pegarlas hubo problemas. Indica que ahí hubo muy buenos ingenieros, pero faltó un arquitecto.

Fue en los años noventa que Dewayne Perry y Alexander Wolf escribieran sobre el concepto de arquitectura (Perry & Wolf, Foundations for the Study of Software Architecture, 1992) e iniciaran un proceso evolutivo que continúa aún hoy. Comenzaron analizando algunos conceptos propios de la arquitectura de construcción y notaron que ciertas nociones eran aplicables al desarrollo del software. La más notable fue el concepto de vista que se verá luego. Pero su principal definición fue:

Arquitectura de software = {Elementos, Forma, Rationale}

Esto es, elementos arquitecturales (componentes de un sistema, elementos de diseño), combinados en un tipo de forma (interconexiones y relaciones) con un detalle de los razonamientos hecho para cada decisión tomada. Este rationale es una parte integral de la arquitectura y explica cómo se han logrado alcanzar los diferentes requerimientos y restricciones del sistema.

El concepto ha ido evolucionando, siempre tomando como base la fórmula presentada por Perry y Wolf. Las definiciones que se usarán para este trabajo son las transcritas a continuación:

Definición según la IEEE 1471- “Arquitectura de Sistema es la organización fundamental de un sistema formada por sus componentes, sus relaciones unos con otros y con el ambiente, y los principios que guían su diseño y evolución” (ISO/IEEE, 2011).

El plano conceptual propuesto por la IEEE (modelo de los conceptos arquitecturales y sus relaciones según la IEEE 1471) se muestra en la Ilustración 1. Plano Conceptual Completo De Arquitectura Software (Según IEEE-1471-2000) Este es un plano completo de todos los conceptos, aunque nos interesa solamente la parte superior para esta definición. Los cuatro elementos superiores se leen así: Para un Sistema, que habita e influencia un Ambiente y cumple con una Misión, existe una Arquitectura. Según el plano, también existen Stakeholders interesados en el sistema. Dentro de los conceptos incluidos en el resto del plano se encuentran los de Descripción Arquitectural y Puntos de Vista que se discutirán más adelante.

Ilustración 1. Plano Conceptual completo de Arquitectura Software (Según IEEE-1471-2000) (ISO/IEEE, 2011)

Definición según ISO 42010- “Conceptos fundamentales o propiedades de un sistema en su ambiente compuesto por sus elementos, relaciones y los principios de su diseño y evolución” (ISO/IEEE, 2011).

El plano conceptual propuesto por IEEE/ISO se muestra en la Ilustración 2. Plan conceptual base de Arquitectura de Software (Según ISO 42010). En la versión de la ISO-42010, en lugar de un plano completo como en el caso de IEEE-1471-2000, se procede a crear varios planos focalizados. En este, comparado con el de IEEE1471-2000, se elimina la relación con la Misión pero se formaliza un concepto nuevo, Preocupación o concern del sistema que es lo que enlaza a este con el Stakeholder. También se menciona la Descripción Arquitectural que se tratará luego.

Ilustración 2. Plan conceptual base de Arquitectura de Software (Según ISO 42010) (ISO/IEEE, 2011)

Definición Según Woods y Rosanski– “La estructura o estructuras del Sistema que incluyen elementos de software, las propiedades externamente visibles de estos y las relaciones entre ellos.” (Woods & Rosanski, 2011).

El plano conceptual propuesto por Woods y Rosanski se muestra en la Ilustración 3. Plano Conceptual Arquitectura de Sistemas (Según Woods y Rosanski. Este plano también incluye el concepto de Descripción Arquitectural, visto más adelante. Este plano tiene los mismos elementos y relaciones básicos de los planos anteriores, pero detalle la composición de la arquitectura como una estructura de Elementos Arquitecturales que se interrelaciones entre sí. Los Elementos Arquitecturales y las Relaciones InterElementos forman parte de la arquitectura como componentes básicos de la estructura.

Las definiciones de la IEEE y la ISO son ambas muy similares debido a que la segunda deriva de la primera. Pero tienen una importante diferencia: para el IEEE 1471 la arquitectura es la simple organización o estructura, mientras que para la ISO 42010, es un conjunto de conceptos. Es importante mencionar que ninguna de las definiciones habla sobre documentación o el diseño, dado que para ambas la arquitectura es algo tangible de un producto real, un sistema ya en funcionamiento, y no una descripción o plano por construir. Claro, en los planos conceptuales de ambas se menciona la descripción arquitectural, pero es importante notar que dicha descripción no es la arquitectura, son conceptos diferentes con relaciones diferentes.

En el caso de Woods y Rosanski, la arquitectura es más que la simple estructura: tiene una importancia especial las propiedades visibles y las interrelaciones entre elementos arquitecturales, tanto así que el plano considera como conceptos de primer orden a los elementos arquitecturales y a las relaciones entre ellos.

Ilustración 3. Plano Conceptual Arquitectura de Sistemas (Según Woods y Rosanski) (Woods & Rosanski, 2011)

Grupos de trabajo

Existen varios grupos que están dedicando esfuerzos a la definición de conceptos y metodologías relacionadas con la arquitectura de sistemas de software. Estos son los más importantes.

IEEE e ISO-WICSA: En el año 2000, la IEEE publicó un conjunto de recomendaciones para el trabajo con descripciones arquitecturales. La ISO en el 2011 tomó dicho trabajo y lo adaptó, publicando un estándar con el mismo fin. Diferentes grupos de trabajo han abocado esfuerzos en la definición de conceptos y de metodologías para generar y administrar la descripción arquitectural (no se confunda con la arquitectura, ver sección siguiente), y actualmente están enfocadas en la compilación de propuestas de marcos de trabajo (frameworks) para la administración arquitectural.

El Instituto de Ingeniería de Software (SEI): Adjunto a la Universidad Carnegie Mellon y patrocinado por el gobierno de los Estados Unidos, tiene un proyecto de investigación sobre arquitectura de software y es uno de los más importantes generadores de literatura al respecto, proponente además de metodologías y filosofías de desarrollo basadas en el trabajo arquitectural. Sus metodologías Views and Beyond (metodología de documentación de descripciones arquitecturales) (Garlan, y otros, 2010) y Architecture Centric Development (metodología de desarrollo basado en trabajo arquitectural previo) (SEI-Carnegie Mellon) son sus principales propuestas actuales.

La Asociación de Arquitectos de Tecnologías de Información (IASA): Es una organización sin fines de lucro que ha asociado arquitectos alrededor del mundo para definir la arquitectura como una profesión (IASA). Se ha abocado a la definición de un Cuerpo de Conocimiento (Body of Knowledge) conocido como ITABOK, que comprende todos los conceptos, metodologías y roles de la arquitectura. La diferencias de esta institución con respecto a las demás es su generalidad: la arquitectura es vista como una base de conocimiento con especializaciones: Arquitectura de Software, Arquitectura de Negocios, Arquitectura de Infraestructura y Arquitectura de Información, que se detallen en la Ilustración 4. La base de conocimiento se fundamenta en cinco pilares: Estrategia de Tecnología de Negocios, Ambiente de Tecnologías de Información, Diseño, Propiedades Cualitativas y Dinámicas Humanas.

Ilustración 4. Especializaciones de Arquitectura de Tecnologías de Información (IASA)

Descripción Arquitectural

La arquitectura se entiende entonces como el conjunto de conceptos, organización y estructura de un sistema real. El trabajo arquitectural es el realizado para poder controlar el desarrollo y evolución de dicho sistema por medio de tales técnicas que permitan visualizar dicha estructura y administrarla. Según ISO 42010, el trabajo arquitectural o architecting, es el proceso de concebir, definir, expresar, documentar, comunicar, mantener, mejorar y certificar la implementación apropiada de una arquitectura durante el ciclo de vida del sistema (ISO/IEEE, 2011). Una herramienta fundamental para dicha tarea es la descripción arquitectural.

Eoin Woods y Nick Rosansky (Woods & Rosanski, 2011) mencionan la descripción arquitectural como el conjunto de productos que documentan una arquitectura de manera que los stakeholders puedan entenderla y que además demuestre que dicha arquitectura cumple con sus preocupaciones. Un Stakeholder es cualquier individuo, equipo, organización o institución que tenga un interés en la realización del sistema. (Woods & Rosanski, 2011) (ISO/IEEE, 2011)

La descripción arquitectural puede requerir más de un producto documental y más de un modelo, dado que dicha descripción puede ser muy compleja para ser representada en un único diagrama (Woods & Rosanski, 2011). La cantidad de aspectos a documentar es tan grande, que puede ser necesario utilizar más de un tipo de modelo y de lenguaje de modelado. Compilaciones con las posibles maneras de documentar han sido realizadas (Garlan, y otros, 2010) y la recomendación de estructuración de dichos modelos se encuentra en el IEEE 1471 y el ISO 42010, basándola en el concepto de Vista.

La ISO 42010 define la descripción arquitectural como un producto de trabajo utilizado para expresar la arquitectura de un sistema de interés (ISO/IEEE, 2011). La descripción arquitectural puede tomar la forma de un documento, un conjunto de modelos, un repositorio de modelos, o cualquier otra forma. El formato no se define en el estándar (ISO/IEEE, 2011). En la Ilustración 6 se muestra el plano conceptual de la descripción arquitectural según ISO 42010. Se puede apreciar que la Descripción Arquitectural describe una Arquitectura de un Sistema bajo Interés de los Stakeholders, que tienen sus Preocupaciones para con el sistema, y para ello utiliza el Rationale de las decisiones y utiliza Vistas Arquitecturales y Modelos para describir todo. Hay un concepto adicional, comparado con la Ilustración 1. Plano Conceptual completo de Arquitectura Software (Según IEEE-1471-2000), que también incluye el plano de descripción arquitectural, y es la mención a las correspondencias (ver detalle en Ilustración 5). Estas indican relaciones de trazabilidad, dependencia, restricción, consistencia, refinamiento, composición, etc, entre elementos de descripción arquitectural como Stakeholders, Preocupaciones, Vistas, Modelos, etc. (ISO/IEEE, 2011)

Ilustración 5. Plano Conceptual de Correspondencias (ISO 42010) (ISO/IEEE, 2011)

Ilustración 6. Plano Conceptual de Descripción Arquitectural (ISO 42010) (ISO/IEEE, 2011)

Decisiones y Rationale.

La definición arquitectural de Perry y Wolf incluye no solo los elementos y la forma, sino también el raciocinio detrás de las decisiones. El ISO 42010 tiene un plan conceptual aparte para el rationale (ver Ilustración 7), y lo define como el registro de la explicación, justificación o razonamiento acerca de las decisiones arquitecturales y las alternativas arquitecturales no escogidas (ISO/IEEE, 2011). Cada Decisión Arquitectural tiene un impacto en algún Elemento de Descripción Arquitectural y puede solventar o crear una nueva Preocupación, por tanto debe estar justificada por un Rationale.

El rationale es muy importante por razones históricas, pero mucho más por la información que brinda al desarrollador para poder tomar nuevas decisiones sobre cambios o ajustes (Tang, Babar, Gorton, & Han, 2005).

Ilustración 7. Plano conceptual de Decisiones Arquitecturales y su Rationale (ISO 42010) (ISO/IEEE, 2011)

Vistas y Puntos de Vista

La descripción arquitectural tal y como lo mencionan Woods y Rosanski, puede ser muy compleja y por tanto no se puede crear usando sólo un modelo (Ref #35). Debido a esto, los estándares IEEE/ISO proponen el uso del concepto de vistas arquitecturales (ISO/IEEE, 2011).

Las vistas y los puntos de vista son la unidad de organización de la descripción arquitectural. Una arquitectura se puede describir usando varias vistas diferentes de la misma arquitectura. A continuación las definiciones formales.

Definición de Punto de Vista por ISO 42010: Un punto de vista es un conjunto de convenciones para construir, interpretar, utilizar y analizar un tipo de Vista Arquitectural. El punto de vista incluye tipos de modelos, lenguajes de puntos de vista y nomenclaturas, métodos de modelaje y técnicas analíticas para enmarcar un conjunto específico de preocupaciones. (ISO/IEEE, 2011)

Definición de Vista por ISO 42010: Una vista expresa la arquitectura del sistema de interés desde la perspectiva de uno o más stakeholders, para tocar preocupaciones específicas, utilizando convenciones establecidas en su Punto de Vista. Una vista Arquitectural consiste de uno o más modelos arquitecturales. (ISO/IEEE, 2011)

El término “vista” fue introducido por Wolf y Perry (Perry & Wolf, Foundations for the Study of Software Architecture, 1992, pág. 42) para denotar la visualización de un aspecto particular de la arquitectura. Los estándares de la ISO y del IEEE sugieren el uso de las vistas, cuya creación se guía por los manuales en los Puntos de Vista (ver la parte inferior del plano conceptual en Ilustración 6), pero dejan abierta su definición (ISO/IEEE, 2011). Es decir, no definen las vistas que pueden ser utilizadas. Fue en 1995 cuando Philippe Kruchten publica su artículo “Architectural Blueprints: The 4+1 View Model of Software Architecture”, donde define cuatro vistas utilizadas en RUP para describir la arquitectura (Ref #21). Este puede considerarse el primer Conjunto de Puntos de Vista.

Eoin Woods publicó un estudio de una serie de conjuntos de puntos de vistas (Woods E. ), incluyendo el de Krunchten, donde se analizan las ventajas y carencias de cada uno. Adicionalmente, Woods propone un conjunto propio de 6 vistas (actualizado a 7 en la segunda edición de su libro “Software System Architecture: Working with stakeholders” (Ref #35) intentando solventar algunas falencias. Del estudio se concluye que ciertos conjuntos tienen más apoyo para sistemas orientados a la información, otros para sistemas orientados al procesamiento y uno orientado al control (Siemens).

Perspectivas y Propiedades Cualitativas

Las propiedades cualitativas mencionadas anteriormente deben ser tomadas en cuenta en la arquitectura desde su concepción. La manera de documentarlas no queda clara en los estándares. En su libro, Woods y Rosanski plantea un nuevo tipo de manual, similar a los puntos de vista, pero enfocado a ser una guía para mejorar una vista existente con tal de cumplir con los requerimientos de las propiedades cualitativas. Estos manuales o guías son llamados Perspectivas (Ref #35).

Definición de Perspectiva según Woods y Rosanski: Colección de actividades, tácticas y guías que son usadas para asegurar que un sistema exhiba un conjunto particular de propiedades cualitativas relacionadas, que requieren considerarse a través de un número de vistas arquitecturales (Ref #35).

Ejemplo de Punto de Vista

Woods y Rosanski dictan su propio conjunto de Puntos de Vista (Ref #35). En la definición de ellos, el punto de vista debe proveer:

1. La lista de posibles stakeholders interesados en la vista
2. Las preocupaciones comunes de esos stakeholders que se tratan en la vista
3. Los modelos que la vista puede utilizar
4. Las tareas requeridas para construir los modelos
5. Las fallas en las que se puede incurrir al construir la vista

Todos estos conceptos sobre arquitectura y su descripción dejan claro que el trabajo arquitectural está fuertemente basado en conocimiento, decisiones y control de estructuras, quedando siempre a un nivel estratégico-táctico sin llegar a la parte operativa que sería el desarrollo de los productos de software. Esta parte táctico-operativa que es el desarrollo de software ha sufrido cambios importantes con el advenimiento de las metodologías ágiles, discutidas a continuación.

Metodologías Ágiles

Como se mencionó antes, en el 2001 un grupo de 17 representantes de nuevas metodologías de desarrollo firmaron el Manifiesto Ágil. Ellos y todos los firmantes hasta ahora se les conocen como “La Alianza Ágil”. (Ref #6). Esta es la transcripción del Manifiesto tal cual aparece en la versión en español que se encuentra en línea:

Manifiesto por el Desarrollo Ágil de Software

Como parte de dicho manifiesto, se presentan 12 principios para el Desarrollo Ágile de Software.

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. “ (Beck, y otros, 2011)

En definitiva, si al desarrollar software utilizas una metodología que respete dichos principios, entonces puedes considerarte que estas en el mundo del agilismo. Las metodologías más utilizadas son las siguientes:

• Programación Extrema
• SCRUM
• Crystal
• LEAN

Programación Extrema (Extreme Programming)

En Octubre de 1999, Kent Beck publica su libro sobre programación extrema, resultado de su trabajo y refinamiento de metodología de desarrollo en Chrysler, y con colaboración de Ward Cunningham y Ron Jeffries. Su principal idea es llevar ciertas prácticas de desarrollo al extremo (Jeffries, What is Extreme Programming?, 1999), como:

1. Programación en pares: Esta práctica consiste en tener dos desarrolladores tomando turnos en el computador para desarrollar la misma aplicación y dándose así retroalimentación continua.
2. Pruebas de unidad completas: En esta práctica, todo código debe tener pruebas de unidad, escritas aun antes de escribir el código. También es llamada Diseño Dirigido por Pruebas (Test Driven Design TDD).
3. Juego de planificación: En esta práctica, la planificación del trabajo se da brevemente una vez cada iteración y no toda al inicio.
4. Proceso continuo: Esta consiste en llevar continuidad con ciertas tareas, tales como integrar constantemente el código, mejorar el diseño por medio de la refactorización y entregar producto frecuentemente, en iteraciones pequeñas.
5. Diseño emergente: Esta se refiere a que se diseña conforme se programa, ayudados por el TDD y la interacción con el cliente.

El diagrama de la Ilustración 8 muestra el ciclo XP descrito por Donvan Wells (Wells, 2000). En XP se sigue un corto ciclo que inicia con la captura de las historias de usuario y un plan de entregables. Luego, utilizando metáfora del sistema (utilizar conceptos y nomenclatura del dominio de negocios) se entra a las iteraciones que es donde se crea, prueba y arregla la entrega, que es usualmente algo pequeño, para iniciar el ciclo nuevamente.

Ilustración 8. Ciclo de Proyecto de XP (tomado de extremeprogramming.org) (Wells, 2000)

Scrum

Jeff Sutherland creó en 1993 una metodología de desarrollo que llamó “SCRUM” (palabra que representa una formación de los equipos de Rugby) (Mitch Lacey & Associates, Inc). La metodología se resume en los siguientes pasos:

1. Un Dueño de Producto crea una lista priorizada de “deseables” llamada Product Backlog.
2. Se inicia con una Planificación de Sprint, donde el equipo toma una pequeña cantidad de deseables de la lista, llamada Sprint Backlog y decide cómo implementarla.
3. El Sprint es un lapso predefinido (usualmente de 2 a 4 semanas) y es el tiempo que tiene el equipo para completar el trabajo del Sprint Backlog actual. Cada día se tiene una reunión para analizar el progreso (Scrum diario).
4. Un miembro del equipo, llamado Scrum Master, mantiene al equipo enfocado en su meta.
5. Al final del Sprint, el trabajo debe estar listo para entregar.
6. El Sprint entonces termina con una revisión del mismo y una retrospectiva (proceso en el que equipo analiza lo actuado para mejorarlo).
7. El ciclo se reinicia al seleccionar otro Spring Backlog de la lista original y comenzar en trabajo de nuevo.

Ilustración 9. Ciclo de Proyecto de SCRUM (Mitch Lacey & Associates, Inc)

La Ilustración 9 muestra el ciclo de proyecto de SCRUM. Una característica importante del proceso es que los backlogs son dinámicos: esto es, la prioridad y los deseables puede variar de un Sprint a otro. La otra característica importante a tomar en cuenta es que el Sprint backlog en curso puede no terminarse completo. En este caso, lo que falta por terminar se mueve al Sprint siguiente. En cualquier caso, si sobra o falta tiempo, esos datos se utilizan para calcular la “velocidad” de trabajo y así mejorar los estimados de los sprints siguientes.

Crystal

Crystal es una familia de metodologías de desarrollo creadas por Alistair Cockburn. Cada metodología se ajusta al tamaño del equipo y del proyecto. La más conocida es Crystal Clear, para equipos de proyectos pequeños. Las metodologías se centran en las personas, no en los procesos. También buscan ser Ultraligeras, reduciendo el papeleo y la burocracia. Por último, buscar ser “estirable hasta que calce”, que implica comenzar con algo pequeño e irlo incrementarlo hasta que se balancee con lo que se necesita (Ref #10).

Crystal se basa en 3 propiedades fundamentales (Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams, 2004):

1. Entrega Frecuente: Significa que el producto debe hacerse disponible a los stakeholders o a un grupo de ellos, sea para ponerlo en producción o para revisión y retroalimentación
2. Mejora Reflectiva: Se trata de tomar tiempo, un poco cada semana o mes, para revisar cuáles cosas están funcionando y cuáles no, proponiendo mejoras en ambos casos y poniéndolas a funcionar en la siguiente iteración.
3. Comunicación Osmótica: Con equipos colocados en el mismo cuarto, las preguntas se hacen abiertas y todos en el grupo puede participar, resultando mejores respuestas e información adicional muy valiosa.

Adicionalmente, Crystal es una metodología más libre y permite que quienes la siguen utilicen sin problema procesos de otras metodologías.

Lean

Lean es una serie de principios basados en la metodología utilizada por Toyota en su fábrica de vehículos. La idea principal es la eliminación de toda práctica o proceso que cause desperdicio de esfuerzo (Ref #29). Algunos de sus principios son:

1. La mayoría de los errores son de naturaleza sistémica, por tanto el sistema de desarrollo debe mejorarse
2. Se debe respetar a las personas para poder mejorar el sistema
3. Hacer las cosas muy temprano causa desperdicio. Hay que hacer las cosas justo cuando se necesitan, just-in-time o JIT
4. Minimizar Complejidad y Retrabajo, haciendo siempre la cosa más simple
5. Eliminar desperdicio y posponer compromiso. Se refiere a evitar gasta de esfuerzo innecesario o la producción de cosas que no se utilizarán. También a no tomar decisiones tempranas sino justo cuando se necesitan.
6. Crear conocimiento.

Los principios de Lean se enfocan en reducir el tiempo de puesta en mercado al remover retrasos en el proceso de desarrollo; utilizando métodos JIT para lograr esto es mucho más importante que mantener a la gente simplemente ocupada.

Existe trabajo orientado a combinar estas metodologías ágiles con el conocimiento y administración arquitectural. El siguiente apartado describe un resumen de dicho trabajo.

Integrando el AK con Agilismo: Propuestas

Administración de Conocimiento Arquitectural

El Conocimiento Arquitectural (o AK por sus siglas en ingles) se define como la representación integrada de la arquitectura de software de un sistema intensivo en software o de una familia de sistemas, junto con las decisiones arquitecturales y su rationale, la influencia externa y el ambiente de desarrollo (Avgeriou, Kruchten, Lago, Grisham, & Perry, 2007). Ya para el 2009 se habían realizado propuestas para el modelado y la administración de tal conocimiento, atrayendo mucho interés en la investigación de esta área (Ref #30).

Modelos propuestos

Tang et al. (Ref #30) realizaron un estudio en 2009 donde analizaron cinco modelos propuestos, de los cuales se ofrece un resumen:

• The Architecture Design Decision Support System (ADDSS): Es una herramienta enfocada en la administración de la información sobre decisiones arquitecturales (Capilla, Nava, Pérez, & Dueñas, 2006). Basada en la idea de una Vista de Decisión propuesta por los autores (ver modelo conceptual en Ilustración 10), se basa en documentar las decisiones utilizando diagramas y texto, que se guardan por iteraciones, permitiendo así el llevar la historia o evolución de la arquitectura. La importancia de este enfoque es su abstracción por medio de una vista nueva, pero su producto es usualmente una serie de reportes (en PDF) que puede tener limitaciones en reutilización.
• Archium. Esta herramienta buscar proveer trazabilidad entre muchos conceptos pero manteniendo este conocimiento durante todo el ciclo de vida del sistema. Trabaja con un lenguaje llamado Archium, que está basado en Java, que se compila para generar modelos ejecutables en una plataforma de ejecución, que es a su vez utilizada para visualizar el conocimiento arquitectural.
• 
  Architecture Rationale and Element Linkage (AREL): Es una herramienta que se focaliza en documentar decisiones y su rationale. Utiliza UML para capturar preocupaciones de diseño, decisiones de diseño y producto del diseño.
• The Knowledge Architect. Esta herramienta se compone de un repositorio, un servidor y varios clientes que permiten capturar el conocimiento arquitectural. Con los clientes se busca poder capturar el conocimiento al momento de creación. Dicho conocimiento es enviado al servidor que lo almacena en el repositorio. Los clientes son creados para ser incorporados a herramientas populares de documentación, de forma que el usuario no tenga que repetir el esfuerzo de ingreso del conocimiento. Por ejemplo, se tienen clientes para Microsoft Word que captura textos y para Microsoft Excel, que ayuda a capturar modelos de análisis arquitectural. También tiene un explorador que permite visualizar y analizar el conocimiento capturado.
• The Process-based Architecture Knowledge Management Environment (PAKME): Creado sobre Hipergate, PAKME es una herramienta web que permite trabajo distribuido. PAKME ofrece captura, mantenimiento, consulta y presentación del conocimiento arquitectural, dividido en artefactos basados en conocimiento, basados en proyecto y conocimiento en general.

Ilustración 10. Meta Modelo Conceptual de Decisiones (Capilla et al.) (Capilla, Nava, Pérez, & Dueñas, 2006)

Estas herramientas y modelos llegan hasta el punto de capturar y administrar el conocimiento arquitectural, pero están pensadas para en ese nivel y no han tomado en cuenta los requerimientos ágiles de trabajo. Hay algunas investigaciones y propuestas orientadas a combinar ambos mundos, algunas de las cuales se discuten a continuación.

Documentación Arquitectural Ágil

Hay varios proponentes de soluciones para utilizar documentación, aunque no necesariamente arquitectural, con las metodologías ágiles. Estos son algunos.

• SEI: David Garland y otro autores del SEI están enfocados en su metodología Views and Beyond (Garlan, y otros, 2010) de documentación arquitectural, basado en el ISO 42010. Un trabajo de Paul Clemmens y otros (Ref #9) analiza la posibilidad de utilizar dicha metodología en el mundo ágil. Proponen una manera de documentar por partes, incremental, que suponen sigue los principios ágiles.
• Scott Ambler: Scott ha sido un pionero en tratar de trabajar con conceptos arquitecturales en el mundo ágil (Ref #2). Propone un principio They Aren’t Gonna Read It (TAGRI) que básicamente indica que mucha documentación no es utilizada y por ende no debe ser producida. Propone entonces crear documentación arquitectural minimalista para efectos de comunicación en dos situaciones particulares: cuando se tienen equipos distribuidos geográficamente y cuando se tengan a futuro proyectos similares que puedan utilizar dicha información.

Trabajo Futuro

Los esfuerzos y resultados para poder utilizar el conocimiento arquitectural a nivel de trabajo ágil son pocos. En este trabajo se ha documentado los conceptos y problemas que presenta el desarrollo actual de las propuestas de administración de conocimiento arquitectural y su incorporación en el movimiento ágil. Se sugiere como trabajos futuros:

1. Plantear estudios de campo que identifiquen los beneficios del trabajo con conocimiento arquitectural en procesos ágiles. Se pueden utilizar metodologías híbrida o mixta de investigación (Ref #14) para capturar los requerimientos documentales para los procesos agilistas.
2. Proponer modelos de información para manejo de la información operativa ágil, que permita extrapolar la información estratégica a nivel arquitectural.
3. Estudiar los problemas de consumo de información por medio de análisis del trabajo diario de desarrolladores agilistas, identificando primero sus necesidades de información y luego la manera en la que la obtienen.

Conclusiones

La gestion de la información estratégica a nivel arquitectural tiene un amplio portafolio de estudios y propuestas, por lo que se muestra mucho más madura ante el enfoque agilista de documentación mínima y necesaria pero no estructurada. Sin embargo, las propuestas y herramientas creadas no han probado ser útiles o aceptadas en el desarrollo ágil. La mayor preocupación de la comunidad de arquitectos es la falta enfoque en el consumo ya que es importante para poder otorgar valor a la información como es requerido por el proceso agilista.

Es menester entonces trabajar en la identificación y clarificación de los requerimientos ágiles de información arquitectural y proponer cambios que permitan la aceptación de tales modelos en el desarrollo agilista.

Por último, debido a la poca investigación de campo existente en el tema de consumo de documentación por parte de agilistas, es requirido proponer e incentivar tales investigaciones en un futuro, con el ánimo de ir cerrando la brecha y dar el valor añadido que requieren las organizaciones.

Referencias

1. Abrahamsson, P., Baba, M. A., & Kruchten, P. (2010). Agility and Architecture: Can They Coexist? IEEE Software, 27(2), 16-22.
2. Ambler, S. W. (13 de Julio de 2010). Agile Architect. Recuperado el 26 de Abril de 2012, de http://www.agilemodeling.com/essays/agileArchitecture.htm
3. Ambler, S. W. (2011). Agile Architecture: Strategies for Scaling Agile Development. Recuperado el 26 de Abril de 2012, de http://www.agilemodeling.com/essays/agileArchitecture.htm
4. Avgeriou, P., Kruchten, P., Lago, P., Grisham, P., & Perry, D. (2007). Architectural Knowledge and Rationale – Issues, Trends, Challenges. ACM SIGSOFT Software Engineering Notes, 32(4), 41-46.
5. Bass, L., Clements, P., & Kazman, R. (2003). SEI Series in Software Engineering: Software Architecture in Practice (Segunda ed.). Addison-Wesley.
6. Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Fowler, M., y otros. (2011). Agile Manifesto. Recuperado el 26 de 04 de 2012, de http://agilemanifesto.org/
7. Buxton, J., & Randell, B. (1969). SOFTWARE ENGINEERING TECHNIQUES, Report on a conference sponsored by the NATO SCIENCE COMMITTEE. Bruselas. Bégica.
8. Capilla, R., Nava, F., Pérez, S., & Dueñas, J. (2006). A web-based tool for managing architectural design decisions. Proceedings of the First Workshop on Sharing and Reusing Architectural Knowledge.
9. Clements, P., Ivers, J., Little, R., Nord, R., & Stafford, J. (2003). Documenting Software Architectures in an Agile World. Pittsburgh, PA 15213-3890: SEI, Carnegie Mellon.
10. Cockburn, A. (2004). Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley Professional.
11. Cockburn, A. (s.f.). Crystal Methodologies. Recuperado el Junio de 2012, de http://alistair.cockburn.us/Crystal+methodologies
12. Fairbanks, G. (2010). Just Enough Architecture: The Risk Driven Model. Crosstalk, 8-11.
13. Garlan, D., Bachmann, F., Ivers, J., Stafford, J., Bass, L., Clements, P., y otros. (2010). Documenting Software Architectures: Views and Beyond (2nd Ed). Addison-Wesley Professional.
14. Hernández Sampieri, R., Fernández Collado, C., & Baptista Lucio, M. (2010). Metodología de la Investigación. México DF: McGraw Hill.
15. IASA. (s.f.). IASA Global. Recuperado el Junio de 2012, de http://www.iasaglobal.org/
16. ISO/IEEE. (13 de Diciembre de 2011). Systems and software engineering — Architecture description ISO/IEC/IEEE 42010. Recuperado el 26 de Abril de 2012, de http://www.iso-architecture.org/42010/
17. Jeffries, R. (1999). What is Extreme Programming? Recuperado el JUnio de 2012, de http://xprogramming.com/xpmag/whatisxp
18. Jeffries, R. (21 de Noviembre de 2001). XPrograming / Essential XP: Documentation. Recuperado el 26 de Abril de 2012, de http://xprogramming.com/articles/expdocumentationinxp/
19. Josuttis, N. (Enero de 2000). ACCU Professionalism in Programming/ Overload Journal #35. Recuperado el 26 de Abril de 2012, de http://accu.org/index.php/journals/509
20. Kruchten , P. (1995). The 4+1 View Model of Architecture. IEEE Software, 12(6), 42-50.
21. Kruchten, P. (1995). Architectural Blueprints—The “4+1” View Model of Software Architecture. IEEE Software, 12(6), 42-50.
22. Louridas, P. (2006). Using Wikis in Software Development. IEEE Software, 23(2), 88-91.
23. Maier, M., Emery, D., & Hilliard, R. (2001). Software architecture: introducing IEEE Standard 1471. Computer, 34(4), 107-109.
24. Mitch Lacey & Associates, Inc. (s.f.). Scrum Alliance. (Mitch Lacey & Associates, Inc) Recuperado el Junio de 2012, de http://www.scrumalliance.org/pages/what_is_scrum
25. Perry, D., & Wolf, A. (1992). Foundations for the Study of Software Architecture. ACM SIGSOFT SOFTWARE ENGINEERING NOTES, 17(4), 40-52.
26. Randell , B., & Buxton, J. (27-31 de Octubre de 1969). SOFTWARE ENGINEERING TECHNIQUES – Report on a conference sponsored by the NATO SCIENCE COMMITTEE. Recuperado el 26 de Abril de 2012, de http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF
27. Royce, W. W. (1970). MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS. Proceedings, IEEE WESCON, 1-9.
28. SEI-Carnegie Mellon. (s.f.). Architecture Centric Practices. Recuperado el Junio de 2012, de http://www.sei.cmu.edu/architecture/research/archpractices/index.cfm
29. Shalloway, A., Beaver, G., & Trott, J. (2009). Lean-Agile Software Development: Achieving Enterprise Agility . Pearson Education.
30. Tang, A., Avgeriou, P., Jansen, A., Capilla, R., & Babar, M. A. (2009). A comparative study of architecture knowledge management tools. The Journal of Systems and Software.
31. Tang, A., Babar, M. A., Gorton, I., & Han, J. (2005). A Survey of the Use and Documentation of Architecture Design Rationale. Proceedings of the 5th Working IEEE/IFIP Conference on Software
32. Architecture (WICSA ’05) IEEE Computer Society. Washington.
33. Wells, D. (2000). Extreme Programming: A gentle introduction. Recuperado el Junio de 2012, de http://www.extremeprogramming.org/
34. Woods, E. (s.f.). Experiences Using Viewpoints for Information Systems Architecture: An Industrial Experience Report. Artechra Limited.
35. Woods, E., & Rosanski, N. (2011). Software System Architecture: Working with Stakeholders using Viewpoints and Perspectives. New Jersey: Addison-Wesley.