3 Atributos de calidad de software

3 Atributos de calidad de software 3.1 Atributos de calidad Los atributos de calidad generales del software son escalabilidad, segurid ad, desempeño, desempeño, y fiabilidad. Los reque requerim rimien ientos tos de los atribu atributo tos s de calid calidad ad son son parte parte de los requer requerim imien iento tos s no funcio funciona nales les de una aplica aplicació ción, n, la cual cual captur captura a las las múlti múltiple ples s faceta facetas s de cómo cómo los 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 pesa pesarr de que que para para much muchas as apli aplica caci cion ones es de IT, IT, dese desemp mpeñ eño o no es real realme ment nte e un problema, es un enfoque en la comunidad de los atributos de calidad. Se sospecha que es así así porque porque es una de las cualida cualidades des de una aplicac aplicación ión que pueden pueden ser a menud menudo o cuantificados cuantificados y validados. validados. Cualquiera que sea la razón, cuando el desempeño importa, es realmen realmente te important importante. e. Las aplicacione aplicaciones s en donde donde su desempeñ desempeño o es pobre pobre en algún algún aspecto crítico de su comportamiento 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 como limitan limitante te como como los que podemos podemos encontrar encontrar en sistema sistemas s militar militares es o robóticos, robóticos, donde si alguna salida es producida en un milisegundo milisegundo o tres ya es demasiado tarde, tarde, realmen realmente te cosas cosas repugnan repugnantes tes y no deseable deseables s pueden pueden suceder. suceder. Pero muchas muchas aplicaci aplicaciones ones necesitan necesitan procesar procesar cientos, cientos, algunas algunas veces miles y decenas decenas de miles miles de transacciones transacciones cada segundo y estos estos son encontrados 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 administración para un almacén grande puede necesitar procesar 50 mensajes por segundo desde socios comerciales. Es impor importan tante te entend entender er precis precisam ament ente e lo que se entien entiende de por por un requer requerim imien iento to 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, apuestas, entonces el negocio pierde dinero y los usuari usuarios os se disgus disgustan tan.. Por lo tanto tanto para para este este escena escenario rio,, la aplica aplicació ción n debe debe ser diseñada diseñada para satisfac satisfacer er es anticipa anticipadam damente, ente, rendimi rendimiento ento máximo máximo y no promedio promedio de rendimiento. De hecho, soportando solo promedio de rendimiento seria un desastre. 3.2.2. Tiempo de respuesta Es una una cara caract cter erís ísti tica ca de late latenc ncia ia (tie (tiemp mpo o en el que que se real realiz iza a una una peti petici ción ó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.