Por lo regular, se conoce hasta el final del desarrollo del sistema de software, si éste cumplió o no con los atributos de calidad que se especificaron en los requerimientos no funcionales. Dicho conocimiento tardío, implica tomar demasiados riesgos innecesarios, un ejemplo es, descubrir fallas en el sistema de software debido a que en la fase de diseño no se eligió apropiadamente una arquitectura. Para reducir tales riesgos y, como una buena práctica de ingeniería, es recomendable llevar acabo evaluaciones a la arquitectura.
La finalidad de este artículo es dar a conocer un panorama general sobre evaluaciones a arquitecturas de software. En él, presento el propósito de evaluar, conceptos sobre atributos de calidad, primeros intentos de evaluación, momentos en los que se pueden realizar evaluaciones, clasificación de las técnicas de evaluación, planeación de evaluaciones, y beneficios que se obtienen al evaluar una arquitectura.
Porqué es necesario evaluar una arquitectura de software
El propósito de realizar evaluaciones a la arquitectura, es para analizar e identificar riesgos potenciales en su estructura y sus propiedades, que puedan afectar al sistema de software resultante, verificar que los requerimientos no funcionales estén presentes en la arquitectura, así como determinar en qué grado se satisfacen los atributos de calidad. Cabe señalar que los requerimientos no funcionales, también son conocidos como atributos de calidad. De acuerdo al estándar IEEE 610.12-1990 [3], un atributo de calidad es una característica que afecta la calidad de un elemento. En esta definición, el término “característica” se refiere a aspectos no funcionales, mientras que el término “elemento” se refiere a un componente o sistema.
Los atributos de calidad se clasifican en dos grupos [4]: operacionales y de desarrollo. Los atributos operacionales son las cualidades del sistema que están en operación, por ejemplo: rendimiento, confiabilidad, disponibilidad, tolerancia a fallas. En cambio, los atributos de desarrollo son las cualidades del sistema que son relevantes desde una perspectiva del desarrollo de software, por ejemplo: facilidad de modificación, facilidad de re-utilización, flexibilidad.
Primeros inicios
Los primeros esfuerzos en realizar evaluaciones a arquitecturas de software utilizando un proceso estructurado y definido, fueron descritos en un trabajo seminal hecho por Parnas y Weiss [5] en 1985. En él se propone utilizar revisiones de diseño activas, que consisten en detectar errores e inconsistencias, por ejemplo aquellos que no fueron detectados en la fase de requerimientos. Este proceso consiste en elaborar una serie de cuestionarios cuidadosamente escritos, de tal manera que el revisor no pueda responderlos de una manera pasiva, es decir, con un “Sí” o un “No”.
Cada cuestionario se diseña para encontrar diferentes tipos de errores, por lo que cada uno, evalúa aspectos específicos del diseño. Estos, a su vez, junto con la documentación del diseño, se entregan para su evaluación a un grupo de revisores expertos en uno o varios aspectos específicos del diseño. En promedio, la duración de dichas revisiones se lleva de uno a dos días, dependiendo de la complejidad del diseño, así como del número de revisores.
¿Cuándo es recomendable evaluar?
La evaluación a la arquitectura puede efectuarse en varios momentos, dependiendo de la etapa de construcción en que se encuentre. La evaluación clásica se efectúa una vez que la arquitectura se ha terminado y aún no se implementa. La evaluación temprana se lleva acabo una, o varias veces durante la etapa de construcción de la arquitectura, mientras que la evaluación tardía, se realiza cuando la arquitectura existe y la implantación se ha completado. Clements, Kazman y Klein [6] proponen dos reglas de oro para determinar el momento de efectuar la evaluación:
1. Realizar una evaluación cuando el equipo de desarrollo inicia a tomar decisiones que afectan directamente a la arquitectura; y...
2. Cuando el costo de no tomar estas decisiones podría pesar más, que el costo de realizar una evaluación.
Técnicas de evaluación
Existen varias técnicas para evaluar arquitecturas de software, que se clasifican en cualitativas y cuantitativas. Dentro de las técnicas de evaluación cualitativas se pueden utilizar: escenarios, cuestionarios o listas de verificación. Por otro lado, en las técnicas de evaluación cuantitativas se pueden emplear: métricas, simulaciones, prototipos, experimentos o modelos matemáticos; en la figura 1 se muestran de manera gráfica estas técnicas.
La mayoría de los métodos de evaluación utilizan escenarios, que son secuencias específicas de pasos que involucran el uso o la modificación del sistema. Por lo regular, las técnicas de evaluación cualitativas son usadas cuando la arquitectura se encuentra en construcción, mientras que las técnicas de evaluación cuantitativas, se usan cuando la arquitectura ya ha sido implantada. Por ejemplo, es posible hacer uso de modelos matemáticos tales como teoría de colas, para medir el desempeño de un conjunto de componentes EJB en una aplicación J2EE [7].
Figura 1. Clasificación de las técnicas de evaluación.
Planear o no la evaluación
Las evaluaciones pueden ser planeadas o no planeadas. Una evaluación planeada es aquella que ha sido contemplada dentro del ciclo de vida de desarrollo, por lo que es parte de las actividades del proyecto. Son varios los beneficios que se obtienen de realizar evaluaciones, algunos de estos son descubrir defectos e inconsistencias en la fase de diseño, asegurar que se cumplan los atributos de calidad, así como reducir los costos del proyecto. Comúnmente una evaluación no planeada, se presenta cuando la arquitectura de software contiene varios defectos que han sido detectados en etapas tardías del desarrollo, por ende, realizar una evaluación no planeada, representa retrasos en los tiempos de entrega, así como un incremento en los costos del proyecto. Es recomendable que en el proyecto se contemple realizar una o varias evaluaciones a la arquitectura.
¿Quiénes participan en la evaluación?
Generalmente las evaluaciones a la arquitectura se hacen por los miembros del equipo de desarrollo, tales como el arquitecto, diseñador y administrador del proyecto. Sin embargo, puede haber excepciones en las que se contrate a un grupo de personas especialistas para realizar la evaluación. El cliente también se interesa por los resultados obtenidos de la evaluación, ya que puede decidir continuar o no con el proyecto, dependiendo de los resultados. Un ejemplo de este caso es el siguiente, tras haber efectuado una evaluación temprana, se determinó que no es posible implantar la arquitectura con la infraestructura disponible, ya que esta no cumplirá con los tiempos de respuesta requeridos por el cliente.
Resultado de la evaluación
Una vez que se ha efectuado la evaluación, se debe elaborar un reporte. Que debe presentarse como un documento preliminar, con la finalidad de que se corrija por las personas que participaron en la evaluación. El contenido del reporte responde a dos tipos de preguntas [6]:
•¿Se ha diseñado la arquitectura mas apropiada para el sistema?
•¿Cuál de las arquitecturas propuestas es la más apropiada para el sistema a construir?
Además de responder estas preguntas, el reporte también indica el grado en que se cumplieron los atributos de calidad.
Conclusiones
En esta primera parte presentamos un panorama general sobre las evaluaciones a las arquitecturas de software. Entre los puntos más importantes destacaron: el propósito de evaluar, los momentos y los tipos de técnicas de evaluación, así como los resultados que se obtienen de ésta. En la próxima ocasión, expondremos de manera detallada, algunos de los métodos de evaluación a arquitecturas de software más usados en la actualidad.
Referencias
1. Len Bass, Paul Clements & Rick Kazman. “Software Architecture in Practice”. SEI Series In Software Engineering. Segunda edición. Addison Wesley, 2003.
2. Anthony Finkelstein & John Dowell. “A Comedy of Errors: The London Ambulance Service Case Study”. Proceedings of 8th International Workshop on Software Specification and Design (IWSSD-8), Schloss Velen; Alemania, Marzo 1996.
3. “Standard Glossary of Software Engineering Terminology.”, Institute of Electrical and Electronics Engineers (IEEE), 1990.
4. Jan Bosch & Peter Molin. “Software Architecture Design: Evaluation and Transformation”. Proceedings of IEEE Engineering of Computer Based Systems Symposium (ECBS ‘99) 1999.
5. David L. Parnas & David M. Weiss. “Active Design Reviews: Principles and Practices”. Proceedings of 18th International Conference on Software Engineering 1985.
6. Paul Clements, Rick Kazman & Mark Klein. “Evaluating Software Architectures”. SEI Series in Software Engineering. Addison Wesley, 2002.
7. Yan Liu & Ian Gorton. “Performance Prediction of J2EE Applications Using Messaging Protocols.” International SIGSOFT Symposium on Component-based Software Engineering (CBSE). Mayo 2005.
Acerca del autor
Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas. Actualmente es profesor de la Universidad de Guadalajara, es miembro de la Association for Computing Machinery ACM y del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org
- Log in to post comments