Published 16 years ago
(updated 13 years ago)
Si tuviésemos que precisar un atributo que defina al software enestos tiempos, seguramente muchos coincidirían en que la complejidad es algo destacable. Esto se manifiesta en el volumen de los productos, utilización de productos COTS (Comercial off the self ), la integración a través de diferentes tipos de interfaces, la interoperabilidad entre diferentes plataformas y la conjunción de más de una tecnología para el desarrollo de un mismo producto. Dicha complejidad también se manifiesta a través de los requerimientos, tanto en cantidad como en los diferentes tipos y prioridades de las necesidades expresadas por las distintas personas interesadas por el producto bajo desarrollo.Muchos de estos requerimientos están expresando atributos que el software debe satisfacer para asegurar una adecuada calidad: desempeño, seguridad, mantenibilidad, etcétera. Estos atributos, reconocidos como “requerimientos no funcionales” o “atributos de calidad” son a veces la causa de importantes desvíos en el desarrollo o de serios problemas en la operación del producto, provocando insatisfacción de los usuarios y frustración de los equipos de desarrollo.
Por otro lado si analizamos el problema desde la óptica de gestión de proyectos, la situación nos presenta un escenario también complejo: múltiples equipos trabajando en diferentes lugares con diferentes culturas, así como diferentes proveedores interactuando con complejas relaciones de trabajo y fuertes restricciones de tiempo y presupuesto. Si bien es cierto que la utilización de modelos de calidad ha contribuido en gran medida a mejorar la capacidad de producir software en las organizaciones, esas mejoras en la práctica se han concentrado en aspectos vinculados con la gestión de los proyectos y con menor énfasis en la mejora de la ingeniería de los productos, aun en niveles avanzados de madurez.
Esta falta de foco en la ingeniería podría atribuirse a una mala interpretación de los modelos o a la minimización del impacto de los métodos en la calidad del producto. Dado el escenario que hemos planteado al inicio, se hace imprescindible que los procesos de desarrollo comiencen a enfocarse en las prácticas que mejor resuelvan
la complejidad de los productos para asegurar que, además de la funcionalidad, se satisfacen adecuadamente los atributos de calidad que el software debe proveer.
Estas prácticas de ingeniería adecuadamente integradas con las prácticas de gestión conforman procesos eficientes, eficaces y por sobre todo proactivos. En este artículo presentamos una visión que apunta a proveer una solución centrada en el diseño de la arquitectura como conductor del proceso de desarrollo, garantizando la calidad del producto y proactividad en todas y cada una de las etapas de fabricación e implantación.
Una definición de arquitectura de software
La arquitectura de un producto complejo de software es uno de los artefactos más importante del ciclo de desarrollo. Si bien sus principios y resultados han sido analizados, definidos y divulgados por un periodo de diez años, su práctica formal por parte de la comunidad profesional, es todavía vaga e imprecisa. Existen muchas definiciones de arquitectura de software, nosotros creemos que una que sintetiza la esencia de la misma es la elaborada por Clemens, Bass y Kazman[1]: “La arquitectura de un programa o sistema
es la estructura o las estructuras del sistema que contienen a los componentes, las propiedades visibles de estos componentes y las relaciones entre ellas.”
De esta definición podemos deducir:
1. La arquitectura es una solución de alto nivel que muestra de qué manera serán resueltos los objetivos de negocio que dan origen al producto. En este sentido podemos decir que la arquitectura del software es “un puente” entre las necesidades de los usuarios y los equipos técnicos que serán responsables del desarrollo.
2. La arquitectura solo se ocupa de mostrar y resolver las propiedades visibles de los elementos (mencionados como atributos de calidad). No interesan los detalles internos de cada uno de ellos.
3. La arquitectura muestra las grandes decisiones de diseño y su justificación, facilitando de esta manera la comprensión por parte de los grupos técnicos.
4. La arquitectura facilita la comunicación entre los diferentes involucrados (stakeholders) en el desarrollo del producto.
5. La arquitectura es la base para facilitar el reuso a diferentes niveles de abstracción.
6. Las revisiones de arquitectura son, junto con la validación de los requerimientos, la primera actividad proactiva de calidad, la cual permite detectar conflictos técnicos y/o defectos en la estructura del producto, reduciendo de esta manera el retrabajo en etapas posteriores del desarrollo.
Por último, la documentación de la arquitectura de software es el artefacto más importante que sintetiza el conocimiento acerca del producto. Ésta no solo contribuye significativamente en el diseño de la estrategia del proyecto (ciclo de vida) sino que también será esencial en el periodo de evolución del producto, y
será de gran utilidad como medio de aprendizaje para el equipo de desarrollo.
Sin entrar en detalles, términos como arquitectura de referencia, patrones de diseño, frameworks de arquitectura, le dan cuerpo a la definición que hemos dado. En los ciclos de vida clásicos el diseño
de arquitectura, por lo general, no está adecuadamente formalizado. Muchas veces resulta común confundir diseño de detalle con arquitectura. Los requerimientos no funcionales son poco considerados en los requerimientos del producto y por consecuencia no incluidos en la definición de la solución, lo que repercute en las tareas de construcción y testing incrementando los defectos y el re trabajo. En el resto de este trabajo presentamos algunas ideas para utilizar de manera eficiente los conceptos de arquitectura de software
a partir de incorporar el proceso de diseño como componente esencial del ciclo de desarrollo.
Qué es un ciclo de vida guiado por la arquitectura
Si bien no hay una definición consensada sobre lo que es un ciclo de vida guiado por la arquitectura, podemos decir que es un ciclo en donde los objetivos de negocios y los atributos de calidad del producto conducen el diseño de la arquitectura, y ésta es la base para la definición del resto del ciclo de producción y evolución a partir de:
• Definir la estructura del proyecto (ciclos de vida, estimaciones, conformación de equipos, plan de comunicación, estrategia de configuration management, plan de pruebas, estrategia de integración e implantación del producto).
• Definir la estrategia de integración entre proveedores.
• Definir los mecanismos de coordinación entre grupos ubicados en diferentes locaciones.
• Definir la estrategia de transferencia de conocimiento a grupos de mantenimiento.
La figura 1, adaptada de Paulish[2], muestra un modelo de ciclo de vida guiado por arquitecturas:
Lo más destacable de esta figura se puede sintetizar en los siguientes puntos:
1. Los requerimientos analizan la funcionalidad y también definen, en base a los objetivos de negocios los atributos de calidad que el producto debe satisfacer.
2. Un análisis global toma los requerimientos y las restricciones del proyecto e identifica los factores que dirigen el desarrollo (drivers), que sirve de entrada al diseño de arquitectura.
3. El diseño de la arquitectura utiliza estos factores identificados y aplicando patrones y tácticas elabora la solución técnica del producto, la cual se sintetiza en un documento de arquitectura, que contiene n vistas en donde cada una de ellas refleja los intereses de cada uno de los stakeholders del producto. Por ejemplo, vista funcional, de información, de desarrollo, de despliegue y de operación. Otro ejemplo se puede encontrar en el modelo 4+1 elaborado por Phillip Kruchten[3] .
4. El producto del diseño de arquitectura es revisado para detectar conflictos entre atributos de calidad, aspectos no cubiertos por el diseño, riegos técnicos y decisiones no formalizadas que puedan
atentar contra la comprensión del producto.
5. El diseño de arquitectura ajustado es utilizado para definir la estrategia de fabricación e implantación del producto. Esta estrategia se plasmará en un ciclo de vida o una combinación de ciclos,
la cual se ve en el Plan de proyecto que gestionará la producción del producto.
6. Todo este marco de trabajo está soportado por un proceso integral de gestión de la configuración y de aseguramiento de la calidad.
Desde el punto de vista de los modelos de calidad, específicamente el CMMI-DEV, el diseño de arquitectura es una entrada importante al procedimiento de configuración que exige IPM, (Integrated Project
Management). Por lo general, IPM es vista como la “tijera” que permite eliminar “lo que se necesita del proceso”. Pero si interpretamos esta práctica vamos a concluir que es mucho más que eso: esta área facilita la definición del mejor proceso que el proyecto necesita a partir de contar con una estrategia adecuada al mismo. Cuando tenemos esta interpretación clara le sacaremos más valor a IPM. El diseño de arquitectura ayuda a definir esta estrategia y plasmarla en el proceso definido para el proyecto.
Métodos prácticos para aplicar a un ciclo guiado por arquitecturas.
El Software Engineering Institute (SEI) viene trabajando desde hace más de diez años en la definición de métodos para soportar los ciclos de vida guiados por la arquitectura. Son métodos prácticos que
se sustentan en el uso de escenarios. Un escenario es una instancia concreta del uso del sistema y se compone de estimulo, elemento estimulado, resultado esperado en base a mediciones y el ambiente
en donde el escenario se produce.
La tabla 1 muestra los métodos, los roles involucrados y qué etapa del ciclo de vida soportan:
QAW es un taller (workshop) en donde se integran los diferentes involucrados para identificar los atributos de calidad que serán drivers del diseño de arquitectura del producto. QAW facilita la resolución temprana de conflictos, obtiene consensos entre los stakeholders y ayuda a mejorar los requerimientos a todos los niveles.
ADD es un método iterativo para diseñar la arquitectura del producto en base a los drivers definidos en el QAW. ADD aplica patrones y tácticas de diseño que apuntan a asegurar que los atributos de calidad estarán presentes en el producto.
ATAM es un método altamente estructurado para evaluar un diseño de arquitectura. ATAM permite detectar, de manera temprana, riesgos técnicos, conflictos entre atributos, puntos sensitivos del diseño y soluciones.
La documentación mediante vistas es una forma de documentar el diseño de arquitectura considerando los intereses de los interesados en el producto. Existen variadas maneras de expresar las vistas y sus interrelaciones. Esta es una lista de las potenciales vistas.
• Funcional. Describe los elementos funcionales del producto, sus responsabilidades, interfaces e interacciones primarias. Esta vista es la que conduce al resto.
• Información. Describe la manera en que la arquitectura almacena, manipula, maneja y distribuye información. Describe una visión estática y dinámica de la infromación dentro del producto.
• Concurrencia. Describe las estructuras de concurrencia del sistema y mapas funcionales para identificar unidades de concurrencia que puedan ser ejecutadas en forma simultanea y la manera en como estas son coordinadas y controladas.
• Desarrollo. Describe la arquitectura que soporta el desarrollo del producto. Representa cuestiones de interés para las personas involucradas en construir, probar, mantener y evolucionar el producto.
• Deployment. Describe el ambiente en el cual el sistema será implantado, incluyendo las dependencias que el sistema tiene en tiempos de ejecución. Mapea cada elemento de software a otros componentes necesarios
para que la ejecución esté de acuerdo a los requerimientos.
• Operación. Describe la manera en cómo el sistema será operado, administrado y soportado en tiempo de operación productiva.
Los métodos se potencian utilizando herramientas de modelado y de soporte a la documentación de la arquitectura tales como Enterprise Architect, o Rational Architect o por ejemplo. Incluso un wiki puede
integrar un repositorio integral de la arquitectura.
Referencias
[1. Bass; Clements & Kazman. “Software Architecture in Practice”. 1998]
[2. Paulish, Danie. “Architecture-Centric Software Project Management”. 2002]
[3. Krutchen, P. “The 4+1 View Model of Architecture”.IEEE Software, Vol 12, nro. 6, 1995]
[sei.cmu.edu/architecture/index.html]
Acerca del Autor
Alejandro Bianchi es analista de sistemas,con un curso de postgrado en Sistemas Expertos de la Universidad Católica de La Plata y un diploma en Gerencia Estratégica de la Universidad Argentina de la Empresa. Socio y presidente de LIVEWARE Ingeniería de Software. Consultor internacional, con más de veintiséis años de experiencia en desarrollo de software, consultoría y administración de tecnología informática.
Nombre de la Empresa: LIVEWARE Ingeniería de Software S.A.
Sitio Web: www.liveware.com.ar
Email: consultas@liveware.com.ar
Por otro lado si analizamos el problema desde la óptica de gestión de proyectos, la situación nos presenta un escenario también complejo: múltiples equipos trabajando en diferentes lugares con diferentes culturas, así como diferentes proveedores interactuando con complejas relaciones de trabajo y fuertes restricciones de tiempo y presupuesto. Si bien es cierto que la utilización de modelos de calidad ha contribuido en gran medida a mejorar la capacidad de producir software en las organizaciones, esas mejoras en la práctica se han concentrado en aspectos vinculados con la gestión de los proyectos y con menor énfasis en la mejora de la ingeniería de los productos, aun en niveles avanzados de madurez.
Esta falta de foco en la ingeniería podría atribuirse a una mala interpretación de los modelos o a la minimización del impacto de los métodos en la calidad del producto. Dado el escenario que hemos planteado al inicio, se hace imprescindible que los procesos de desarrollo comiencen a enfocarse en las prácticas que mejor resuelvan
la complejidad de los productos para asegurar que, además de la funcionalidad, se satisfacen adecuadamente los atributos de calidad que el software debe proveer.
Estas prácticas de ingeniería adecuadamente integradas con las prácticas de gestión conforman procesos eficientes, eficaces y por sobre todo proactivos. En este artículo presentamos una visión que apunta a proveer una solución centrada en el diseño de la arquitectura como conductor del proceso de desarrollo, garantizando la calidad del producto y proactividad en todas y cada una de las etapas de fabricación e implantación.
Una definición de arquitectura de software
La arquitectura de un producto complejo de software es uno de los artefactos más importante del ciclo de desarrollo. Si bien sus principios y resultados han sido analizados, definidos y divulgados por un periodo de diez años, su práctica formal por parte de la comunidad profesional, es todavía vaga e imprecisa. Existen muchas definiciones de arquitectura de software, nosotros creemos que una que sintetiza la esencia de la misma es la elaborada por Clemens, Bass y Kazman[1]: “La arquitectura de un programa o sistema
es la estructura o las estructuras del sistema que contienen a los componentes, las propiedades visibles de estos componentes y las relaciones entre ellas.”
De esta definición podemos deducir:
1. La arquitectura es una solución de alto nivel que muestra de qué manera serán resueltos los objetivos de negocio que dan origen al producto. En este sentido podemos decir que la arquitectura del software es “un puente” entre las necesidades de los usuarios y los equipos técnicos que serán responsables del desarrollo.
2. La arquitectura solo se ocupa de mostrar y resolver las propiedades visibles de los elementos (mencionados como atributos de calidad). No interesan los detalles internos de cada uno de ellos.
3. La arquitectura muestra las grandes decisiones de diseño y su justificación, facilitando de esta manera la comprensión por parte de los grupos técnicos.
4. La arquitectura facilita la comunicación entre los diferentes involucrados (stakeholders) en el desarrollo del producto.
5. La arquitectura es la base para facilitar el reuso a diferentes niveles de abstracción.
6. Las revisiones de arquitectura son, junto con la validación de los requerimientos, la primera actividad proactiva de calidad, la cual permite detectar conflictos técnicos y/o defectos en la estructura del producto, reduciendo de esta manera el retrabajo en etapas posteriores del desarrollo.
Por último, la documentación de la arquitectura de software es el artefacto más importante que sintetiza el conocimiento acerca del producto. Ésta no solo contribuye significativamente en el diseño de la estrategia del proyecto (ciclo de vida) sino que también será esencial en el periodo de evolución del producto, y
será de gran utilidad como medio de aprendizaje para el equipo de desarrollo.
Sin entrar en detalles, términos como arquitectura de referencia, patrones de diseño, frameworks de arquitectura, le dan cuerpo a la definición que hemos dado. En los ciclos de vida clásicos el diseño
de arquitectura, por lo general, no está adecuadamente formalizado. Muchas veces resulta común confundir diseño de detalle con arquitectura. Los requerimientos no funcionales son poco considerados en los requerimientos del producto y por consecuencia no incluidos en la definición de la solución, lo que repercute en las tareas de construcción y testing incrementando los defectos y el re trabajo. En el resto de este trabajo presentamos algunas ideas para utilizar de manera eficiente los conceptos de arquitectura de software
a partir de incorporar el proceso de diseño como componente esencial del ciclo de desarrollo.
Qué es un ciclo de vida guiado por la arquitectura
Si bien no hay una definición consensada sobre lo que es un ciclo de vida guiado por la arquitectura, podemos decir que es un ciclo en donde los objetivos de negocios y los atributos de calidad del producto conducen el diseño de la arquitectura, y ésta es la base para la definición del resto del ciclo de producción y evolución a partir de:
• Definir la estructura del proyecto (ciclos de vida, estimaciones, conformación de equipos, plan de comunicación, estrategia de configuration management, plan de pruebas, estrategia de integración e implantación del producto).
• Definir la estrategia de integración entre proveedores.
• Definir los mecanismos de coordinación entre grupos ubicados en diferentes locaciones.
• Definir la estrategia de transferencia de conocimiento a grupos de mantenimiento.
La figura 1, adaptada de Paulish[2], muestra un modelo de ciclo de vida guiado por arquitecturas:
Lo más destacable de esta figura se puede sintetizar en los siguientes puntos:
1. Los requerimientos analizan la funcionalidad y también definen, en base a los objetivos de negocios los atributos de calidad que el producto debe satisfacer.
2. Un análisis global toma los requerimientos y las restricciones del proyecto e identifica los factores que dirigen el desarrollo (drivers), que sirve de entrada al diseño de arquitectura.
3. El diseño de la arquitectura utiliza estos factores identificados y aplicando patrones y tácticas elabora la solución técnica del producto, la cual se sintetiza en un documento de arquitectura, que contiene n vistas en donde cada una de ellas refleja los intereses de cada uno de los stakeholders del producto. Por ejemplo, vista funcional, de información, de desarrollo, de despliegue y de operación. Otro ejemplo se puede encontrar en el modelo 4+1 elaborado por Phillip Kruchten[3] .
4. El producto del diseño de arquitectura es revisado para detectar conflictos entre atributos de calidad, aspectos no cubiertos por el diseño, riegos técnicos y decisiones no formalizadas que puedan
atentar contra la comprensión del producto.
5. El diseño de arquitectura ajustado es utilizado para definir la estrategia de fabricación e implantación del producto. Esta estrategia se plasmará en un ciclo de vida o una combinación de ciclos,
la cual se ve en el Plan de proyecto que gestionará la producción del producto.
6. Todo este marco de trabajo está soportado por un proceso integral de gestión de la configuración y de aseguramiento de la calidad.
Desde el punto de vista de los modelos de calidad, específicamente el CMMI-DEV, el diseño de arquitectura es una entrada importante al procedimiento de configuración que exige IPM, (Integrated Project
Management). Por lo general, IPM es vista como la “tijera” que permite eliminar “lo que se necesita del proceso”. Pero si interpretamos esta práctica vamos a concluir que es mucho más que eso: esta área facilita la definición del mejor proceso que el proyecto necesita a partir de contar con una estrategia adecuada al mismo. Cuando tenemos esta interpretación clara le sacaremos más valor a IPM. El diseño de arquitectura ayuda a definir esta estrategia y plasmarla en el proceso definido para el proyecto.
Métodos prácticos para aplicar a un ciclo guiado por arquitecturas.
El Software Engineering Institute (SEI) viene trabajando desde hace más de diez años en la definición de métodos para soportar los ciclos de vida guiados por la arquitectura. Son métodos prácticos que
se sustentan en el uso de escenarios. Un escenario es una instancia concreta del uso del sistema y se compone de estimulo, elemento estimulado, resultado esperado en base a mediciones y el ambiente
en donde el escenario se produce.
La tabla 1 muestra los métodos, los roles involucrados y qué etapa del ciclo de vida soportan:
QAW es un taller (workshop) en donde se integran los diferentes involucrados para identificar los atributos de calidad que serán drivers del diseño de arquitectura del producto. QAW facilita la resolución temprana de conflictos, obtiene consensos entre los stakeholders y ayuda a mejorar los requerimientos a todos los niveles.
ADD es un método iterativo para diseñar la arquitectura del producto en base a los drivers definidos en el QAW. ADD aplica patrones y tácticas de diseño que apuntan a asegurar que los atributos de calidad estarán presentes en el producto.
ATAM es un método altamente estructurado para evaluar un diseño de arquitectura. ATAM permite detectar, de manera temprana, riesgos técnicos, conflictos entre atributos, puntos sensitivos del diseño y soluciones.
La documentación mediante vistas es una forma de documentar el diseño de arquitectura considerando los intereses de los interesados en el producto. Existen variadas maneras de expresar las vistas y sus interrelaciones. Esta es una lista de las potenciales vistas.
• Funcional. Describe los elementos funcionales del producto, sus responsabilidades, interfaces e interacciones primarias. Esta vista es la que conduce al resto.
• Información. Describe la manera en que la arquitectura almacena, manipula, maneja y distribuye información. Describe una visión estática y dinámica de la infromación dentro del producto.
• Concurrencia. Describe las estructuras de concurrencia del sistema y mapas funcionales para identificar unidades de concurrencia que puedan ser ejecutadas en forma simultanea y la manera en como estas son coordinadas y controladas.
• Desarrollo. Describe la arquitectura que soporta el desarrollo del producto. Representa cuestiones de interés para las personas involucradas en construir, probar, mantener y evolucionar el producto.
• Deployment. Describe el ambiente en el cual el sistema será implantado, incluyendo las dependencias que el sistema tiene en tiempos de ejecución. Mapea cada elemento de software a otros componentes necesarios
para que la ejecución esté de acuerdo a los requerimientos.
• Operación. Describe la manera en cómo el sistema será operado, administrado y soportado en tiempo de operación productiva.
Los métodos se potencian utilizando herramientas de modelado y de soporte a la documentación de la arquitectura tales como Enterprise Architect, o Rational Architect o por ejemplo. Incluso un wiki puede
integrar un repositorio integral de la arquitectura.
Referencias
[1. Bass; Clements & Kazman. “Software Architecture in Practice”. 1998]
[2. Paulish, Danie. “Architecture-Centric Software Project Management”. 2002]
[3. Krutchen, P. “The 4+1 View Model of Architecture”.IEEE Software, Vol 12, nro. 6, 1995]
[sei.cmu.edu/architecture/index.html]
Acerca del Autor
Alejandro Bianchi es analista de sistemas,con un curso de postgrado en Sistemas Expertos de la Universidad Católica de La Plata y un diploma en Gerencia Estratégica de la Universidad Argentina de la Empresa. Socio y presidente de LIVEWARE Ingeniería de Software. Consultor internacional, con más de veintiséis años de experiencia en desarrollo de software, consultoría y administración de tecnología informática.
Nombre de la Empresa: LIVEWARE Ingeniería de Software S.A.
Sitio Web: www.liveware.com.ar
Email: consultas@liveware.com.ar
- Log in to post comments