3 Atributos de calidad de software

3.1 Atributos de calidad

Los atributos de calidad generales del software son escalabilidad, seguridad,
desempeño, y fiabilidad.
Los requerimientos de los atributos de calidad son parte de los requerimientos no
funcionales de una aplicación, la cual captura las múltiples facetas de cómo los
requerimientos funcionales de una aplicación son logrados.
Para que tenga sentido los requerimientos de atributos de calidad deben ser específicos
de cómo una aplicación debe lograr una necesidad dada.

3.2. Desempeño
A pesar de que para muchas aplicaciones de IT, desempeño no es realmente un
problema, es un enfoque en la comunidad de los atributos de calidad. Se sospecha que es
así porque es una de las cualidades de una aplicación que pueden ser a menudo
cuantificados y validados. Cualquiera que sea la razón, cuando el desempeño importa, es
realmente importante. Las aplicaciones en donde su desempeño es pobre en algún
aspecto crítico de su comportamiento a menudo se convierte en un atropellamiento en la
carretera de la ingeniera de software.
Un requerimiento de calidad de desempeño define una métrica que indica la cantidad de
trabajo que una aplicación debe de realizar en un determinado tiempo y/o plazo que debe
cumplir para el correcto funcionamiento. Pocas aplicaciones de IT tiene un tiempo real
muy duro como limitante como los que podemos encontrar en sistemas militares o
robóticos, donde si alguna salida es producida en un milisegundo o tres ya es demasiado
tarde, realmente cosas repugnantes y no deseables pueden suceder. Pero muchas
aplicaciones necesitan procesar cientos, algunas veces miles y decenas de miles de
transacciones cada segundo y estos son encontrados en muchas grandes
organizaciones, especialmente en los mundos de finanzas, telecomunicaciones y
gobierno.
Desempeño usualmente se manifiesta asimismo en las siguientes características.

3.2.1. Rendimiento.
Rendimiento es una característica de la cantidad de trabajo que una aplicación debe de
realizar en una unidad de tiempo. El trabajo es típicamente caracterizado en
transacciones por segundo (tps) o mensajes procesados por segundo (mps).por ejemplo
una aplicación bancaria en línea podría tener que garantizar que puede ejecutar 1000
transacciones por segundo a los clientes desde banco por Internet. Un inventario del
sistema de administración para un almacén grande puede necesitar procesar 50
mensajes por segundo desde socios comerciales.
Es importante entender precisamente lo que se entiende por un requerimiento de
rendimiento. Es el rendimiento promedio durante un periodo de tiempo determinado o un
rendimiento máximo? Esto es una distinción crucial.
Una ilustración de esto es una aplicación para hacer apuestas en eventos como una
carrera de caballos. La mayoría del tiempo una aplicación de este tipo hace poco trabajo,
y por lo tanto el requerimiento promedio de rendimiento es bajo fácil de realizar.
Pero todo el tiempo hay un evento de carrera, por lo tanto cada tarde, el periodo de 5 o
menos minutos antes de cada carrera se ve cientos de apuestas en el mismo segundo. Si
la aplicación no es capaz de procesar estas apuestas, entonces el negocio pierde dinero y
los usuarios se disgustan. Por lo tanto para este escenario, la aplicación debe ser
diseñada para satisfacer es anticipadamente, rendimiento máximo y no promedio de
rendimiento. De hecho, soportando solo promedio de rendimiento seria un desastre.

3.2.2. Tiempo de respuesta

Es una característica de latencia (tiempo en el que se realiza una petición y es
contestada) una aplicación muestra una transacción de negocio en proceso. Tiempo de
respuesta es mas a menudo asociado en el tiempo que una aplicación toma para
responder a una entrada. Un rápido tiempo de respuesta permitirá a los usuarios trabajar
más eficazmente, y en consecuencia es bueno para el negocio. Un ejemplo excelente es
una aplicación de punto de venta soportando un gran almacén. Cuando un artículo es
escaneado en la caja rápida, un segundo o menos responde desde el sistema con el
precio del articulo lo cual significa que el cliente puede ser atendido rápidamente.
Otra vez, es siempre importante distinguir entre los tiempos de respuesta garantizados y
los tiempos de respuesta promedio. Algunas aplicaciones quizá necesiten que todas las
solicitudes sean respondidas en un tiempo limite definido a esto se le llama tiempo de
respuesta garantizado. Otras aplicaciones quizá especifiquen un tiempo de respuesta
promedio permitiendo tiempos de espera mayores cuando la aplicación esta
extremadamente ocupada (hora pico). También en el ultimo de los casos para un limite
superior el requerimiento del tiempo de respuesta tiene que ser especificado. Por ejemplo
el 95% de las solicitudes deben de ser procesadas en menos de 4 segundos y ninguna
solicitud debe tomar mas de 15 segundos.

3.2.3. Tiempo Límite.

Todos han escuchado del sistema de pronostico de tiempo que toma 36hrs para producir
el pronostico del tiempo para el siguiente dia. Es un excelente ejemplo de un
requerimiento para cumplir con el desempeño en un plazo determinado de tiempo.
Un sistema para el pago del seguro social debe de completar el pago a tiempo para poder
hacer el deposito en la cuenta del reclamante en un dia determinado. Si el pago se
completa fuera de tiempo el reclamante no tendra su deposito en el tiempo esperado y
esto puede causar severos problemas no solo para el reclamante. En general cualquier
aplicación que tiene una ventana de tiempo limite debe tener un requerimiento de
rendimiento en un plazo determinado.
Estos tres atributos de desempeño pueden ser claramente especificados y validados, sin
embargo existe una dificultad que hay que evitar, esta se encuentra en la definición de
una transacción, solicitud o mensaje. Básicamente esta es la definición de una aplicación
de carga de trabajo. La cantidad de procesamiento requerido para una transacción
determinada es una característica especifica de la aplicación. Incluso en una misma
aplicación existen diferentes tipos de solicitudes o transacciones que pueden variar
desde rápidas consultas a las bases de datos hasta complicadas actualizaciones en
múltiples base de datos distribuidas.

Simplemente no existe una medida generica de carga de trabajo depende

completamente de que es lo que esta haciendo la aplicación por lo tanto cuando se esta
acordando cumplir con un desempeño determinado debemos de ser muy precisos acerca
de la carga o transacciones que nos estamos comprometiendo a cumplir.

3.2.4 Desempeño para el sistema ICDE

Desempeño en el sistema ICDE es un atributo de calidad importante. La llave del
requerimiento de desempeño pertenece al carácter interactivo del ICDE. Como el usuario
va a realizar sus tareas, la parte del cliente en la aplicación ICDE es atrapar las acciones
claves y enviarlas al servidor del ICDE para almacenarlas. En consecuencia en muy
importante que los usuarios del ICDE no experimenten retrasos usando sus aplicaciones
mientras el programa del ICDE atrapa y almacena los eventos.
El usuario capturando y la aplicacion generadora de eventos en la GUI (interfaz grafica de
usuario) se basa en la explotacion de un sitema de plataforma especifica de llamadas API.
Los API’s proveen ganchos en la GUI y manejan mecanismos de eventos en un sistema de
operación. Implementando esta funcionalidad es un asunto de la aplicación del ICDE
cliente, por lo tanto es responsabilidad del equipo de clientes del ICDE de asegurarse que
sea llevado a cabo eficientemente como lo mas rapido posible.
Una vez que el evento es atrapado, el ICDE cliente debe de llamar al servidor para
almacenar el evento en el almacenamiento de datos. Es vital por lo tanto que esta
operación no aporte ningún retraso que el usuario pueda experimentar. Por esta razon
cuando un evento es detectado, es escrito en una cola de memoria en el ICDE cliente.
Una vez que el evento esta en la cola, la detección del evento regresa y espera capturar
el siguiente evento. Otra tira de eventos sigue desde la cola y llama al servidor ICDE.
Esta solución dentro del desacoplo de la captura de eventos y almacenamiento del ICDE
cliente. Una escritura retrasada en el servidor no puede retrasar el código de la GUI.
Desde la perspectiva del servidor ICDE esto es crucial. El servidor debe ser diseñado para
almacenar eventos en el almacenamiento de datos lo mas rápido posible. Pero el diseño
debe tener garantizado que solo habrá una solicitud de cliente por maquina de usuario en
circulación en cualquier instante.
Por lo tanto para el servidor ICDE, es clave que los requerimientos de desempeño fueran
fáciles de especificar. Debe de proveer un promedio de tiempo de respuesta de menos de
un segundo para las solicitudes del ICDE cliente.

3.3. Escalabilidad
Vamos a empezar con una definición representativa de la escalabilidad.
“como una buena solución a un problema va a funcionar cuando el tamaño del problema
aumenta”
Esto es muy usual en un contexto de arquitectura. Nos dice que la escalabilidad es acerca
de cómo un diseño puede hacer frente con algún aspecto de los requerimientos que
aumentan de tamaño en la aplicación. Para que se concrete el requisito de atributo de
calidad, necesitamos entender exactamente que es lo que se espera para ser grande.
Aquí hay algunos ejemplos.

3.3.1. Solicitud de carga

Basado sobre alguna mezcla de solicitudes definidas sobre una plataforma de hardware
dada, una arquitectura para una aplicación de servidor puede ser designada para
soportar a 100 tps en una carga máxima, con un promedio de un segundo de tiempo de
respuesta. Si esta solicitud de carga fuera a crecer a 10 veces, la arquitectura puede
soportar esta carga aumentada???
En el mundo perfecto y sin capacidad de hardware adicional, y como las cargas
aumentan, el rendimiento de la aplicación debe permanecer constante y el tiempo de
respuesta por solicitud debe aumentar solo linealmente. Una solución escalable va a
permitir una capacidad adicional de procesamiento para desplegar el aumento del
rendimiento y disminuir el tiempo de respuesta. Esta capacidad adicional s puede
desplegar en dos formas, una de esas el añadir mas computadoras (con un poco mas de
memoria) para las maquinas donde la aplicación corre (scale up), la otra seria la
distribución de la aplicación sobre múltiples maquinas (scale out). Esto esta ilustrado en
la figura 6.
Scale up trabaja bien si la aplicación tiene multiples subprocesos, o instancias de
multiples procesos que pueden ser ejecutados juntos en una misma maquina. El ultimo
por supuesto va a tomar la memoria adicional y los recursos asociados.
Scale out trabaja bien si hay poco o no hay trabajo requerido se administra las
distribución de las solicitudes entre las multiples maquinas. El objetivo es mantener cada
maquina con la misma carga de trabajo. Distribuir la carga eventualmente entre
multiples maquinas es conocido como carga-balanceada.

3.3.2 Conexiones simultáneas

Una arquitectura puede ser diseñada para soportar 1000 usuarios. Como va a responder
la arquitectura si esta numero crece significativamente? Si un usuario conectado
consume algunos recursos, entonces es probable que habrá un limite en el numero de
conexiones que pueden ser soportadas efectivamente.
Un ejemplo clásico de este problema en una arquitectura de un ISP (Proveedor de
servicios de internet). Cada vez que un usuario se conecta al servicio, la aplicación ISP
genera un nuevo proceso en su servidor que es el responsable de distribuir los anuncios
dirigidos al usuario. Esto funciona muy bien, pero cada proceso consume memoria
considerable y recursos de procesamiento, aun cuando el usuario solamente este
conectado sin hacer nada. Una prueba rápida revelo que los servidores del ISP pueden
solo soportar acerca de 2000 conexiones antes de que su memoria virtual se agote. Esto
hizo que las operaciones del ISP escalaran para soportar 100,000 usuarios que es una
propuesta muy cara, y eventualmente, a pesar de los esfuerzos en rediseñar, esto fue
una causa raiz del ISP para salir del negocio.

3.3.3 Tamaño de los Datos

Un cuarto de chat, puede ser diseñado para procesar mensajes de un tamaño promedio
esperado.

3.3.4. Implementacion.
Como los esfuerzos son involucrados en la implementacion o modificacion de una
aplicación para un incremento base. Este podria incluir esfuerzos para distribución,
configuración y actualizacion con nuevas versiones. Una solucion ideal podria proveer
mecanismos automaticos que puede desplegar y configurar dinámicamente una
aplicación al nuevo usuario, registrando la captura de la información en un proceso. Esto
es de hecho exactamente como muchas aplicaciones son distribuidas hoy en dia en
Internet.

3.3.5. Algunos pensamientos sobre escalabilidad

Diseñar arquitecturas escalables no es facil. En muchos casos, la necesidad de escalar
tempranamente en un diseño no es muestra y no se especifica como parte de los
requerimientos de los atributos de calidad. Se necesita a un arquitecto experto para
asegurar que los enfoques no escalables no son introducidos como un componente
central arquitectónico. Aun si la escalabilidad es requerida como atributo de calidad,
validando que por una solucion propuesa esta satisfaga a menudo no solo en terminos
practicos de calendario o costos. Es por eso que es importante para un arquitecto tratar
de confiar y probar diseños y tecnologias.

3.3.6 Escalabilidad en la aplicación ICDE

El mayor requerimiento de escalabilidad en la aplicación ICDE es de soportar el numero
de usuarios esperados en la gran implementacion anticipada del ICDE. Los
requerimientos especifican que es aproximadamente 150 usuarios. El servidor de la
aplicación ICDE debe por lo tanto se capaz de manejar una carga pico de 150 solicitudes
desde los ICDE clientes.
3.4 Modificabilidad
El atributo de calidad Modificabilidad es una caracteristica de que tan facil es poder
cambiar una aplicacion para abastecer nuevos requerimientos funcionales y no
funcionales. Prediciendo que la modificabilidad requiere de un costo estimado de esfuero
y dinero para realizar cambios. Solo sabras cuanto fue el costo hasta que el cambio se
haya completado entonces descubriras que tan bueno fue tu estimacion.
Las caracteristicas de modificabilidad solo son relevantes en el contexto de una
determinada solucion arquitectonica. Esta solucion debe estar expresada al menos
estructuralmente como un conjunto de componentes, la relacion de los componentes y
una descripción de cómo los componentes interactuan con el ambiente. Entonces evalyar
la modificabilidad necesita al arquitecto para afirmar probables cambios que
capturan/obtinen como estan involucrados los requerimientos. Algunas veces el grado de
certeza de los cambios en muy bajo. De hecho pueden inclusos ser especificados en la
planeacion del proyecto para las siguientes versiones. Aunque mucho del tiempo para las
posibles modificaciones se obetendra de los involucrados y de la experiencia del
arquitecto. Definitivamente algunas veces la suerte y adivinación debe de estar en
nuestro lado.
Ejemplos de cambios de escenarios:
• Proporcionar acceso a la aplicación atravez de firewalls ademas de los firewalls ya
existentes.
• Incorporar nuevas caracteristicas para los kioscos de autoservicio
• Reemplazar un componente de la aplicación que sale fuera de servicio (COTS).
• La aplicación necesita ser portada desde la plataforma Linux a la de Windows.
Para cada escenario el impacto debe ser evaluado. Este impacto rara vez es facil de
calcular. En mucho de los casos lo mejor que se puede lograr es un conveniente analisis
de impacto de los componentes en la arquitectura que necesitaran ser modificados o una
demostración de cómo la solucion puede ajustarse son tener que hacer cambios.
Finalmente basado sobre el costo, tamaño o la estimacion de esfuerzos para los
componentes afectados, algunas cuantificaciones del costo del cambio puede hacerse. Si
existen cambios difíciles y complejos, esto puede ser una debilidad en la arquitectura que
puede justificar mas tarde la consideración de un rediseño.

3.4.1 modificabilidad para la aplicación ICDE

Seria que el rango de los eventos atrapados y almacenados se extienda para los clientes
del ICDE. Aquí se tiene que hacer una modificación en el cliente, en el servidor y en el
almacenamiento de datos.

3.5 Seguridad
Seguridad es un tema técnico complejo que puede solo ser tratado con un poco de
superficialidad. Seguridad se reduce al entendimiento de los requerimientos precisos de
seguridad para una aplicación y la elaboración de mecanismos para soportarlos. Los
requerimientos más comunes relacionados con seguridad son:
• Autentificación: aplicaciones que verifican la identidad de sus usuarios y otras
aplicaciones con las cuales se comunican.
• Autorización: Autentifica los usuarios y aplicación que tiene derechos definidos
de acceso a los recursos del sistema. Por ejemplo algunos usuarios pueden tener
solo acceso de lectura a los datos de la aplicación mientras que otros tienen de
lectura y escritura.
• Encriptación: los mensajes enviados para/desde de la aplicación son encriptados
• Integridad: esta asegura que el contenido del mensaje en transito no se
alterado.
• No-repudio: el remitente del mensaje tiene una prueba de envio y el receptor se
asegura de la identidad del remitente. Esto significa que no puede negar su
participación en el mensaje.
Estos son bien conocidos y tecnologias ampliamente usadas para soportar estos
elementos de seguridad. El (SSL) protocolo de capa de conexión segura y la
infraestructura de clave publica (PKI) son comúnmente usadas en aplicación de Internet
para proveer autentificación, encriptación y no repudio.

3.6.1 Seguridad para la aplicación ICDE

La autentificación de los usuarios del ICDE y de los terceros del ICDE es ewl principal
requerimiento de seguridad para el ICD. Para la version 1.0 el usuario proporcionar el
usuario y password de acceso los cuales son verificados por la base de datos. Esto les
proporciona acceso a la información en el almacenamiento de datos asociado con sus
actividades. La version 2.0 debera soportar lo mismo autentificación par los usuarios y
extenderse para poder manejar a terceros. Tambien que exista la portabilidad de que los
terceros esten ejecutando de manera remota y accesando a la información del ICDE
sobre redes inseguras, por eso la información que se intercambie debe de estar
encriptada.

3.6 Disponibilidad
Disponibilidad esta relacionada a la fiabilidad de una aplicación. Si una aplicación no esta
disponible para ser usada cuando se necesita, entonces es poco probable que este
cumpliendo sus requerimientos funcionales. Disponibilidad es relativamente facil de
medir. En terminos de especificación muchas aplicaciones de IT deben de estar
disponibles al menos durante horas de oficina. La mayoria de los sitios de Internet desean
un 100% de disponibilidad, porque en el Internet no existen horarios de oficina.
Fallas en aplicaciones pueden causar que no esten disponibles. Las fallas atacan en la
fiabilidad de una aplicación, la cual usualmente es medida por el tiempo entre fallas. La
duracion de cualquier periodo de no disponibilidad esta determinado por la cantidad de
tiempo que toma detectar la falla y reiniciar el sistema.
Replicar los componentes es una estrategia tratada y probada para la alta disponibilidad.
Cuando la replica de un componente falla, la aplicación puede continuar ejecutando
usando replicas que todavía siguen funcionando. Esto lo puede llevar a la degradacion del
rendimiento mientras en componente fallido se cae, pero la fiabilidad no esta
comprometida.
Recuperabilidad esta cercanamente relacionada con disponibilidad. Una aplicación es
recuperable si esta tiene la capacidad de restablecer los niveles requeridos de
rendimiento y recuperar datos afectados después de una aplicación o sistema falle. Un
sistema de base de datos es un ejemplo clásico de un sistema recuperable. Esto significa
reiniciar la aplicación del servidor y resolver cualquier transacción que estaba pendiente
cuando la falla ocurrió.

3.6.1 Disponibilidad para la aplicación ICDE

Mientras una alta disponibilidad para la aplicación ICDE es deseable, solo es crucial que
va a estar disponible solo en las horas de oficina del ambiente de trabajo desplegado,
esto deja un amplio margen de tiempo inactivo para actualizar el sistema, respaldar y
darle mantenimiento. La solución también debe incluir mecanismos tales como
componentes de replicación para asegurar el 100% de disponibilidad como sea posible en
horas de oficina.

3.7 Integracion
Integración esta relacionado con la facilidad con la cual una aplicación puede ser
incorporada en un contexto mas amplio de la aplicación. El valor de una aplicación o
componente puede frecuentemente en gran medida ser incrementado si la funcionalidad
o datos pueden ser usados en diferentes caminos que el diseñador originalmente no
anticipo. La estrategia mas generalizada para proveer integración a través de la
integración de datos o con una aplicación de interfaz de programación (API).
La integración de datos envuelve almacenar los datos de una aplicación que manipula en
diferentes maneras para que otras aplicaciones puedan accesar. Esta puede ser una
simple base de datos estándar para almacenar datos, o quizas implementando
mecanismos para extraer los datos en un formato conocido como XML o con una coma
que separa el texto del archivo para que otras aplicaciones puedan accesar.
Con la integración de datos, las diferentes maneras en que los datos son usados por otras
aplicaciones esta fuera de control del dueño original de los datos. Esto es porque la
integración de los datos y las reglas del negocio impuestos por la aplicación son
temporales.

3.7.1 Integración para la aplicación ICDE

Los requerimientos de integración para el ICDE gira entorno a la necesidad de soportar
analistas de herramientas (terceros). Debe de tener un mecanismo bien definido y
entendido para que los terceros tengan acceso a los datos del ICDE en el
almacenamiento de datos.

3.8 Otros atributos de calida

• Portabilidad: que una aplicación puede ser ejecutada fácilmente

software/hardware en una plataforma diferente para la que fue desarrollada.
Portabilidad depende de las opciones de tecnología de software usadas para
implementar la aplicación, y las características de las plataformas donde necesita
ser ejecutada.
• Capacidad de Prueba: que tan fácil o difícil se puede probar una aplicación? Las
decisiones de diseño tempranas pueden en gran medida afectar la cantidad de
casos de prueba que son requeridos. Entre mas complejo sea el diseño, mayor
sera la dificultad para probarlo a fondo.
• Soportabilidad: esta es una caracteristica de que tan facil una aplicación es
soportada una vez que ha sido implementada. Soporte tipicamente envuelve el
diagnostico y solucion de problemas que ocurren mientras la aplicación esta en
uso. Sistemas soportables tienden a proveer facilidades para diagnosticar, tales
como registros de errores que causan las fallas.