Requerimientos y Arquitectura

Como mencionamos en el número anterior, la arquitectura de software se enfoca en aspectos de diseño estructural del sistema con el fin de satisfacer ciertos requerimientos clave para el sistema, además de guiar el desarrollo del mismo. En este artículo nos enfocaremos en describir la relación que existe entre los requerimientos y la arquitectura de software.

Recordando requerimientos

Recordemos un poco sobre qué son los requerimientos. Generalmente se considera que los requerimientos de un sistema se pueden dividir en dos categorías: Requerimientos Funcionales (RFs) y Requerimientos No Funcionales (RNFs). De acuerdo a Wiegers [1], los RFs engloban los distintos tipos de requerimientos que se reflejan en los comportamientos de la aplicación y que incluyen:

• Requerimientos de negocio. Motivación de negocio para que exista un sistema.
• Requerimientos de usuario. Comportamiento del sistema, frecuentemente se expresan en forma de casos de uso.
• Requerimientos funcionales detallados. Complementan a los casos de uso (generalmente se describen usando el verbo “deber”).
• Requerimientos de sistema. Describen el mínimo hardware y software para que un sistema de información pueda funcionar.

Por otra parte, los RNFs tienen que ver con la manera en que el sistema soporta a los RFs. Estos incluyen:

• Reglas de negocio. expresan reglas de la organización que deben ser soportadas por el sistema.
• Atributos de calidad. se describen más adelante.
• Restricciones. Expresan aspectos que deben considerarse al realizar el diseño y limitan las decisiones que se pueden tomar.
• Interfaces externas. Especificaciones de interfaces de otros sistemas con los que se interactúa.

Los requerimientos de negocio deben identificarse al inicio del desarrollo de un sistema. Dichos requerimientos permiten comprender, desde una perspectiva de negocio, la motivación que existe de realizar un sistema. Para ejemplificar este concepto, imaginemos a la compañía “xyz” que se dedica a la comercialización de productos de diversos fabricantes. Actualmente cuenta con sucursales en varias localidades de la zona sur de la República Mexicana y desea expandir su negocio a través de la venta de productos por Internet. Un objetivo de negocio para esta compañía es “Ofrecer los productos de la empresa a través de un portal en dos etapas: el primer año será dirigido al mercado Mexicano y el siguiente año al mercado internacional.”

Drivers de la arquitectura

Dentro de los requerimientos que se consideran para el desarrollo de un sistema y que se derivan de los objetivos de negocio, existe un subconjunto que tiene una gran importancia relativa a la arquitectura. Estos requerimientos se conocen en inglés como drivers de la arquitectura. El término “drivers” puede traducirse como “guías”, ya que estos requerimientos “guían” el diseño de la arquitectura del sistema. Una estructuración correcta del sistema permitirá satisfacer la mayoría de estos drivers.

Los drivers de la arquitectura incluyen principalmente a los atributos de calidad. Además de esto, incluyen a un subconjunto de los casos de uso que se consideran como primarios. Los casos de uso primarios son aquellos de mayor importancia o de mayor complejidad para el negocio. Por último, las restricciones también son consideradas como drivers arquitecturales.

El hecho de que los drivers sean un subconjunto de todos los requerimientos del sistema puede verse como una ventaja pues es posible comenzar a realizar el diseño de la arquitectura antes de haber terminado de documentar todos los requerimientos. Ciertas metodologías de desarrollo como por ejemplo el Rational Unified Process recomiendan, de hecho, que se siga este enfoque. Retomando el ejemplo anterior, un caso de uso primario podría ser el realizar consultas del catálogo de productos. El criterio para elegir este caso de uso como primario es su importancia relativa a la satisfacción del objetivo de negocio y el hecho de que la consulta de catálogos involucra realizar conexiones hacia los sistemas de los fabricantes. Una restricción para dicho sistema podría ser que se usen librerías y herramientas open source.

Atributos de calidad

Como se mencionó previamente, los atributos de calidad forman parte de los RNF del sistema. Son características medibles que permiten expresar y evaluar el grado de satisfacción de los usuarios y/o diseñadores (es decir la calidad) con respecto al sistema. Cabe señalar que no son la única métrica de calidad de un sistema, la ausencia de defectos es otra métrica clave en este rubro. Existen distintas categorías de atributos de calidad y éstas se clasifican con respecto a la importancia que tienen ya sea para los clientes o para la organización de desarrollo. Entre las más comunes están:

• Desempeño. Tiempo de respuesta del sistema con respecto a un estímulo.
• Seguridad. La facultad del sistema de resistir a ataques.
• Modificabilidad. Costo de realizar cambios en el sistema.
• Usabilidad. Qué tan fácil es para el usuario realizar una tarea particular y el tipo de soporte que el sistema provee al usuario.
• Facilidad de prueba. Sencillez con la cual se pueden identificar defectos.

Conviene señalar que no existen definiciones universales en cuanto a las distintas categorías de atributos de calidad. En ese sentido, lo más conveniente es definir una categoría en el contexto del sistema que se está desarrollando.

Un aspecto esencial con respecto a los atributos de calidad es que se debe procurar, en la medida de lo posible, expresarlos de manera cuantitativa. No tiene sentido, por ejemplo, decir que las respuestas del sistema deben ser “rápidas” ya que no es posible evaluar esto de manera objetiva. A pesar de que los atributos de calidad deben ser expresados de manera cuantitativa, no existe una métrica única asociada con cada una de las categorías de atributo de calidad; es tarea del arquitecto identificar la mejor manera de expresar este tipo de requerimientos. Por otro lado, se debe tener especial cuidado de no imponer métricas arbitrarias (y excesivas) tan sólo con el fin de satisfacer la necesidad de expresar los atributos de calidad de manera cuantitativa. Por ejemplo, exigir un tiempo de respuesta demasiado corto provocará que se tomen decisiones de diseño que pueden resultar complejas y costosas. Una disponibilidad muy elevada igualmente va a requerir de ciertas decisiones con un costo elevado (por ejemplo: sistemas redundantes). De forma general, al momento de identificar una métrica, es necesario asegurarse que el valor que se le asocia se justifica y está alineado con los objetivos de negocio del sistema y que no es simplemente una ocurrencia.

El Software Engineering Institute propone que los atributos de calidad sean especificados usando “escenarios” [2]. Un escenario expresa una respuesta medible del sistema ante un estímulo en un contexto particular. El escenario se expresa como una frase que contiene seis partes que incluyen el estímulo, la fuente del estímulo, el artefacto que recibe el estímulo, el entorno al momento de recibir el estímulo, la respuesta del sistema al estímulo y la métrica para evaluar la respuesta. Una ventaja de esta técnica de especificación es que un escenario es, automáticamente, un caso de prueba para el sistema. Regresando a nuestro ejemplo, podemos considerar un atributo de calidad que se refiera a “la facilidad para agregar un nuevo idioma al sistema”. Dicho atributo pertenecería a la categoría de modificabilidad, y esta sería la forma de documentarlo como escenario.

1. Fuente: Un desarrollador.
2. Estímulo: Desea portar la aplicación al idioma inglés.
3. Artefacto: Código.
4. Entorno: En etapa de producción.
5. Respuesta: La modificación es realizada sin necesidad de recompilar.
6. Métrica: En menos de 16 horas hombre.

Como se puede apreciar, el atributo de calidad es medible, se alinea con el objetivo de negocio (ventas en el mercado internacional) y la métrica se justifica con base en los datos históricos de tiempo de la empresa de desarrollo.

Para terminar

Una vez definidos, los drivers son la entrada para el proceso de diseño de la arquitectura (que será descrito en próximas entregas de esta serie). Los atributos de calidad juegan un papel especialmente importante en este sentido y como se mencionó previamente, el satisfacerlos requerirá tomar decisiones de diseño particulares. Por ejemplo, para satisfacer el driver de modificabilidad expresado previamente una posible solución será concentrar todo el texto de la aplicación en un archivo de propiedades separado del código que pueda ser fácilmente cambiado y que no requiera de recompilar el sistema. Dada la importancia que tienen los drivers arquitecturales en relación con el diseño de la arquitectura, se debe tener especial cuidado de capturarlos antes de comenzar a realizar el diseño. Algunas recomendaciones al respecto son las siguientes:

• Comenzar por la identificación de los objetivos de negocio del sistema.
• Enfocarse inicialmente en la documentación de los casos de uso primarios.
• Identificar restricciones.
• Incluir dentro de las entrevistas de requerimientos preguntas enfocadas a obtener información relacionada con los atributos de calidad.
• Identificar métricas para los atributos de calidad y revisar si dichas métricas tienen un sustento, es decir, se alinean con los objetivos de negocio.
• Priorizar y verificar los atributos de calidad involucrando al cliente.

Referencias:

[1] K. Wiegers, “Software Requirements”, 2nd Edition, Microsoft Press, 2003

[2] L. Bass, P. Clements, R. Kazman, “Software Architecture in Practice”, 2nd Edition, Addison Wesley, 2003