Cada elemento de los modelos que hemos estudiado se denomina un requerimiento funcional, de tal manera que podemos afirmar que los requerimientos funcionales son todos aquellos que se pueden modelar mediante los artefactos que ya hemos estudiado (diagramas, especificaciones).
Los requerimientos NO funcionales son aquellos que no se pueden modelar no aparecen en los casos de uso. Existen tres tipos de requerimientos no funcionales
[GOR06]:
- RESTRICCIONES TÉCNICAS: Restringen la tecnología que se puede usar, generalmente son no negociables. Por ejemplo, hay que usar la misma tecnología de las aplicaciones que ya posee la empresa.
- RESTRICCIONES DE NEGOCIOS: Restringen el diseño por razones de negocios, no tienen que ver con lo técnico y generalmente no son negociables. Por ejemplo, "uno de nuestros mayores accionistas es el Sr. Bill Gates, por lo tanto sólo podemos usar tecnología Microsoft".
- ATRIBUTOS DE CALIDAD: Requerimientos de escalabilidad, disponibilidad, facilidad de cambio, portabilidad, usabilidad, desempeño, etc. Les preocupan a los usuarios y otros interesados (stakeholders). Estos se prestan a la negociación porque cada uno de estos requerimientos tiene un costo, de tal manera que se debe hacer un análisis costo-beneficio.
LOS ATRIBUTOS DE CALIDAD DEL SOFTWARE:Se pueden usar para comparar soluciones de software que resuelvan el mismo problema, o alternativas de solución. Además, serán usados para evaluar el nivel de calidad de la solución elegida. Para obtener cada uno de estos atributos hay que invertir un dinero, de tal manera que uno se debe preguntar si existe la viabilidad económica para obtener el requerimiento. Esta viabilidad depende de qué tantas utilidades le va a generar el software a la empresa ó si forma parte de un proceso considerado estratégico o crítico.
Algunos atributos de calidad son: escalabilidad, seguridad, desempeño, disponibilidad. Generalmente se llaman las "ilidades" del proyecto. Para que estos reuerimientos sean significativos, es necesario que sean específicos acerca de lo que debe lograrse.
Por ejemplo, alguien puede decir
"la aplicación debe ser escalable". Resulta que en un proyecto de software hay muchas cosas que pueden escalar. Debe soportar más usuarios conectados simultáneamente? Debe almacenar una enorme cantidad de datos? Debe distribuirse a una enorme cantidad de usuarios? Todas las anteriores? Hay que ser más específicos cuando hablamos de escalabilidad, por ejemplo:
"Debe ser posible escalar la distribución de los iniciales 100 usuarios dispersos geográficamente a 10,000 sin un incremento en el esfuerzo para la instalación y la configuración".
Este requerimiento concreto me llevaría a una solución del tipo "baje el instalador del Internet y córralo usted mismo".
Algunos atributos de calidad son muy difíciles de probar. No parece viable bajar y configurar la aplicación en 10,000 máquinas para ver si la solución funciona. Entonces entendemos que además de específicos, los requerimientos de calidad deben ser medibles y posibles de probar o verificar.
Existen muchos atributos de calidad y una descripción exhaustiva requeriría un esfuerzo de tipo enciclopedia. Vamos a analizar sólo algunos.
DESEMPEÑO
No muchas aplicaciones requieren realmente un elevado desempeño, pero es un atributo muy solicitado, parece ser porque es fácilmente cuantificable y validable. Pero cuando realmente es importante, se convierte en algo crítico que puede hacer viable o no un determinado proyecto.
Este requerimiento establece una métrica que puede ser la cantidad de trabajos que debe realizar por unidad de tiempo, o los plazos que se deben cumplir en una aplicación. Algunos campos donde se requiere desempeño es en las aplicaciones de tiempo real de tipo militar y de robótica, donde el hecho de que se demore la respuesta algunos milisegundos más de la cuenta puede originar resultados horribles, por ejemplo, que la bomba no caiga en el cuartel enemigo sino en la población civil.
Las aplicaciones que necesitan procesar miles de transacciones por segundo se encuentran en el mundo de las grandes empresas financieras, de telecomunicaciones y del gobierno.
Algunas medidas para el desempeño son:
Rendimiento (Throughput): Medida de la cantidad de trabajo que se realiza por unidad de tiempo. Típicamente se mide en transacciones por segundo (tps) ó en mensajes por segundo (mps). Por ejemplo, una aplicación bancaria podría tener que garantizar que puede realizar 1,000 tansacciones por segundo, mientras que un sistema de gestión de inventario de un supermercado, necesita garnatizar que puede procesar 50 mensajes por segundo.
Hay que comprender el significado de este tipo de requerimiento. Existe el
rendimiento promedio que se mide durante un día entero de trabajo o un período largo de tiempo. También tenemos el
rendimiento pico, que se mide en períodos muy cortos de tiempo. Por ejemplo, en un sistema para procesar apuestas en un hipódromo, la mayor parte del tiempo hay pocas transacciones por segundo, pero cinco minutos antes de que empiece la carrera, las apuestas se disparan. El sistema debe poder procesar todo este caudal de transacciones porque en estos cinco minutos es cuando el negocio obtiene la mayoría de sus ganancias. Por lo tanto debe especificarse un rendimiento pico, y tener unas enormes máquinas aunque sea solamente para soportar estos cinco minutos. Si diseñamos este sistema con el rendimiento promedio, nos encaminaremos al desastre.
Respuesta en tiempo: También se denomina
tiempo de latencia e indica el tiempo que se toma el sistema para responder a una solicitud de usuario. Un mejor tiempo de respuesta le permite a los usuarios un mejor desempeño en sus trabajos, lo cual es bueno para los negocios. Un ejemplo típico es "la aplicación debe presentar la respuesta máximo un segundo después de la solicitud".
Hay que diferenciar entre tiempo promedio y tiempo garantizado de latencia. El
tiempo garantizado significa que todas las solicitudes se van a procesar en un tiempo menor o igual al garantizado. El
tiempo promedio se mide en el largo plazo de tal manera que algunas solicitudes se podrían demorar más que el promedio cuando el sistema está muy ocupado. Un ejemplo de este tipo de requerimiento es "el 95% de las solicitudes deben ser procesadas en menos de cuatro segundos y ninguna solicitud debe tomar mas de 15 seundos".
Plazos: Existe una leyenda urbana acerca de un sistema para pronosticar el clima de las siguientes 24 horas, que tardaba 36 horas en procesar. Esto nos da una buena idea de lo que es un plazo. Generalmente los plazos se asocian a sistemas de procesamiento por lotes. Por ejemplo, la nómina de la Universidad se debe procesar para que los profesores tengan el dinero en sus cuentas el 30 de cada mes. La matrícula académica debe realizarse antes del primer día de clases del semestre. El no cumplir el plazo ocasionará severos contratiempos a la organización.
Algo muy importante a tener en cuenta es que la definición de lo que es una transacción, un mensaje o un lote de trabajo es muy particular de cada aplicación y por lo tanto no es dable comparar el desempeño de aplicaciones que hacen cosas distintas. No hay una medida estandard de la carga de trabajo.
ESCALABILIDAD
Se pude definir de la siguiente manera: “Qué tan bien trabajará la solución a algún problema cuando el tamaño del problema se incremente.” Esta definición nos indica que algún aspecto del problema va a crecer, pero un problema puede tener varios aspectos importantes, entonces para especificar la escalabilidad como un requerimiento hay que definir cual aspecto del problema va a crecer. Algunos ejemplos:
Carga Solicitada
Suponga que un servidor de aplicaciones se ha diseñado para soportar una carga de 100 tps en carga pico, con un tiempo de respuesta promedio de un segundo. Si esta carga solicitada fuera a crecer diez veces, puede la arquitectura soportar el incremento de carga?
En un mundo perfecto, a medida que se incremente la carga, si no se ha hecho ningún cambio en el hardware y en la arquitectura, el volúmen de transacciones debería permanecer constante y entonces se incrementaría el tiempo de respuesta linealmente, es decir, para una carga de 1000 tps el tiempo de respuesta sería de 10 segundos.
Una solución escalable permitiría distribuir capacidad adicional de procesamiento para mantener el tiempo de respuesta en lo solicitado. Hay dos formas de hacer esto: agregar más capacidad de procesamiento (y posiblemente más memora) a la máquina donde se están procesando las transacciones, lo que se llama ESCALAR HACIA ARRIBA, ó distribuir la aplicación sobre múltiples máquinas, lo que se denomina ESCALAR HACIA FUERA.
Conexiones Simultáneas
Un sistema puede estar diseñado para soportar 1000 usuarios simultáneos. Cómo responde la arquitectura si este número crece significativamente? Si un usuario conectado consume algún recurso, entonces probablemente habrá un límite al número de conexiones que efectivamente pueden ser soportadas.
Tamaño de los Datos
Cómo se comporta una aplicación a medida que crecen los datos? Por ejemplo, en una sala de chat cómo se comportará el sistema si el tamaño de los mensajes crece significativamente? O si los datos almacenados de una aplicación crecen de manera inesperada?
Distribución
Cual es el esfuerzo para distribuir una aplicación a un conjunto creciente de usuarios? Qué tal si luego toca modificarla? Esto incluye el esfuerzo para distribuir, configurar y actualizar con nuevas versiones. Una solución ideal sería un procedimiento automatizado para instalar y configurar la aplicación para un nuevo usuario, capturando en el proceso información de registro. Se usan mucho los instaladores por Internet.
Muchas veces, la escalabilidad no es un requerimiento explícito, pero todo buen ingeniero debe diseñar la forma como va a crecer su solución porque una de las leyes de los sistemas es la siguiente:
“El sistema siempre crecerá”.
MODIFICABILIDAD
Podríamos enunciar otra de las leyes de los sistemas, que tiene que ver con este tema:
“El sistema cambiará”.
Es un hecho de la vida que las cosas cambian, los requerimiento funcionales y no funcionales cambian, y habrá que tener en cuenta de qué forma el nuevo sistema va a aceptar los cambios.
La modificabilidad es una medida de qué tan fácil podría ser cambiar una aplicación para cumplir nuevos requerimientos funcionales y no funcionales. Note que en la frase anterior se usa la palabra PODRIA. Predecir la modificabilidad requiere un estimativo del esfuerzo y/o costo de hacer un cambio.
Básicamente se trata de trabajar varios escenarios de cambio, porque existe gran incertidumbre acerca de qué cosas van a cambiar.
SEGURIDAD
Existen varios requerimientos de seguridad, entre los más populares están:
Autenticación
La capacidad de verificar la identidad de los usuarios y otras aplicaciones con las que se comunique el software.
Autorización
Los derechos de los usuarios, los cuales podrían tener accesos de lectura o escritura a algunas porciones de datos ó la posibilidad de realizar algunas operaciones. La idea es que no todos los usuarios tienen los mismos derechos, como mínimo, el usuario administrador tiene derechos diferentes del usuario cliente.
Encriptamiento
La capacidad de hacer ilegibles para terceros los mensajes enviados hacia/desde la aplicación.
Integridad
Asegurar que los contenidos de los mensajes no son alterados durante su tránsito por la red.
No Repudio
El emisor de un mensaje tiene prueba de envío y el receptor del mensaje tiene asegurada la identidad del emisor. Esto significa que luego ninguno de los dos puede negar su participación en el intercambio de mensajes.
DISPONIBILIDAD
Se relaciona con la confiabilidad de una aplicación. Si una aplicación no está disponible para su uso cuando se necesita, entonces es implrobable que cumpla sus requerimientos no funcionales. Es fácil de especificar y medir. Muchas aplicaciones deben estar disponibles durante las horas laborales. La mayoría de sitios de Internet necesitan estar disponibles el 100% del tiempo porque allí no existen horarios.
Una medida es entonces el porcentaje de tiempo disponible:
Tiempo disponible / tiempo requerido
Las fallas disminuyen la disponibilidad y la confiabilidad de una aplicación. Una medida de esto es el tiempo medio entre fallas. La duración del sistema fuera de servicio depende del tiempo que tarde en ser reparado (tiempo de recuperación).
INTEGRACIÓN
Es la facilidad con que una aplicación puede ser incorporada de manera útil en el contexto de una aplicación más amplia. La integración se puede dar de dos formas: Permitiendo que otros accesen los datos de la aplicación o creando programas de interfaz (APIs) que controlen el acceso a los datos para terceros.
PORTABILIDAD
La capacidad de que una aplicación sea ejecutada fácilmente sobre diferentes plataformas de software/hardware diferentes de la plataforma para la que fue diseñada.
VERIFICABILIDAD (Testability)
Qué tan fácil o difícil es probar una aplicación? Esta característica depende de la complejidad del software, pero también tiene que ver su modularidad, la posiblidad de probar sus partes constituyentes. Se puede medir con la cantidad de casos de prueba necesarios para probar todas las características de la aplicación.
SOPORTABILIDAD
Una medida de qué tan fácil es soportar una aplicación una vez que ha sido distribuída. El soporte incluye diagnóstico y solución de problemas. Los sistemas soportables proporcionan facilidades explícitas para diagnóstico tales como históricos o logs de errores que registran las causas de las fallas y están construidos de manera modular para garantizar que la parte que falle sea pequeña y fácil de reemplazar.
REFERENCIAS:[GOR06] GORTON, Ian. Essential Software Architecture. Germany, Springer Verlag Berlin Heidelberg, 2006. ISBN 3-540-28713-2.
