Post on 05-Dec-2014
Arquitectura de Software
Clase 2:
Atributos de Calidad de Software
1
Objetivos
Entender la importancia de la calidad del
software
Conocer los atributos de calidad del
software
2
Temas
La calidad del software
Introducción a los atributos de calidad
Clasificaciones de los atributos
Descripción de los principales atributos
de calidad
3
La Calidad del Software
Antecedentes
Calidad, es la aptitud de un producto o servicio para
satisfacer las necesidades del usuario
La calidad del software es una preocupación a la que
se dedican muchos esfuerzos. Sin embargo, el
software casi nunca es perfecto.
Todo proyecto tiene como objetivo producir
software de la mejor calidad posible, que cumpla, y si
puede, supere las expectativas de los usuarios
4
¿Qué es la Calidad del Software?
Calidad de software es la totalidad de
rasgos y atributos de un producto de
software que le apoyan en su capacidad de
satisfacer sus necesidades explícitas o
implícitas. [ISO 9126]
La calidad del software es el grado que
posee el software de una combinación
deseada de cualidades o atributos. [IEEE]
5
¿Qué es la Calidad del Software?
Según Barbacci (1995) la calidad de software se
define como el grado en el cual el software posee
una combinación deseada de atributos. Tales
atributos son requerimientos adicionales del sistema
(Kazman 2001), que hace referencia a características
que este debe satisfacer, diferentes a los
requerimientos funcionales.
Estas características o atributos se conocen con el
nombre de atributos de calidad, los cuales se definen
como las propiedades de un servicio que presta el
sistema a sus usuarios (Barbacci 1995).
6
Atributos de Calidad (QAs)
La arquitectura de software se ocupa del diseño de sistemas de software que satisfagan un conjunto de requerimientos de atributos de calidad:
◦ Escalabilidad
◦ Seguridad
◦ Rendimiento
◦ Confiabilidad, …
Se parte de la premisa de que la arquitectura de software determina los atributos de calidad
◦ ¿Es cierto?
◦ ¿Las decisiones arquitectónicas pueden afectar atributos de calidad específicos?
◦ ¿Las decisiones arquitectónicas permiten analizar los conflictos entre los atributos de calidad?
7
Atributos de Calidad (QAs)
8
Clasificaciones para los Atributos de
Calidad
A través de las siguientes definiciones:
FURPS+
ISO 9126
Gorton
SEI
9
FURPS+
Clasificación propuesta por Robert Grady de HP
que representa:
◦ Funcionality / Funcionalidad
◦ Usability / Usabilidad
◦ Reliability / Confiabilidad
◦ Performance / Rendimiento
◦ Supportability / Soportabilidad
◦ + requerimientos de diseño, requerimientos de
implementación, requerimientos de interfaces,
requerimientos físicos.
Los requerimientos funcionales representan las
principales características de un producto.
10
FURPS+
Los otros requerimientos, URPS, son generalmente
significativos para la arquitectura de un sistema de
software.
El + en el acrónimo se usa para identificar categorías
adicionales que representan restricciones.
◦ Restricciones de diseño: p. ej. se debe usar una base de
datos.
◦ Requerimientos de implementación: estándares de
codificación, lenguajes de implementación, y límites de
recursos. P. ej. se debe usar Oracle 11.
◦ Requerimientos de interfaz: restricciones en formatos o
sistemas con los que interactúa el sistema.
◦ Requerimientos físicos: hardware que debe usar el sistema.
11
ISO 9126
Modelo de calidad de los productos de software:
ISO 9126. No se busca un producto perfecto, sino el
necesario y suficiente para los diferentes
involucrados.
Aspectos de calidad:
◦ Interna: medible a partir de las características intrínsecas,
como el código fuente.
◦ Externa: medible en el comportamiento del producto, como
en las pruebas.
◦ En uso: durante la utilización por parte del usuario.
12
ISO 9126
13
ISO 9126
En general, la norma define:
◦ 6 atributos, propiedades de un bien o producto, de
calidad
◦ Cada atributo está dividido en subatributos
◦ Cada uno de los subatributos contiene varias métricas
Una métrica es cualquier medida o conjunto de
medidas destinadas a conocer o estimar el tamaño u
otra característica de un software o un sistema de
información, generalmente para realizar
comparativas o para la planificación de proyectos de
desarrollo.
14
ISO 9126
Los involucrados en un sistema de software
deben participar desde el comienzo del ciclo de
vida del sistema en la selección de los atributos
de calidad que debe satisfacer el sistema:
◦ Funcionalidad
◦ Usabilidad
◦ Mantenibilidad
◦ Confiabilidad
◦ Eficiencia
◦ Portabilidad
15
Gorton
La Arquitectura de software aborda los
requerimientos no funcionales; es decir, aquellos
que no aparecen en los casos de uso. Áreas de
requerimientos no funcionales:
◦ Restricciones técnicas: restricciones de diseño sobre
tecnologías o herramientas. Usualmente no son
negociables.
◦ Restricciones de negocio: restricciones de diseño por
razones del negocio. Usualmente tampoco son
negociables.
◦ Atributos de calidad: define los requerimientos de la
aplicación en términos de escalabilidad, disponibilidad,
modificabilidad, etc. 16
Gorton
Atributos de calidad
Performance
Escalabilidad
Modificabilidad
Seguridad
Disponibilidad
Integración
17
Gorton
Especificación de un atributo de calidad
Arquitectos frecuentemente dicen:
◦ “Mi aplicación debe ser rápida/segura/escalable”
Los atributos de calidad (QAs) debe ser hechos precisos/medibles para el diseño del sistema, por ejemplo:
◦ “Debe ser posible escalar la aplicación de 100 usuarios iniciales geográficamente dispersos a 10,000 sin incrementar el esfuerzo/costo de la instalación y configuración.”
Deben ser concretos
18
SEI
La ingeniería de requerimientos es un proceso
cíclico que involucra: obtener, especificar, validar y
validar requerimientos.
Tipos de requerimientos:
◦ Funcionales: qué debe hacer el sistema
◦ No funcionales: con qué calidad debe funcionar el
sistema
◦ Restricciones: límites con los que se debe construir el
sistema
La arquitectura es crítica para el logro de los
atributos de calidad, dichos atributos deben ser
diseñados y evaluados a este nivel
19
SEI
El SEI considera que hay seis atributos
principales de calidad en un sistema de software:
◦ Disponibilidad
◦ Modificabilidad
◦ Rendimiento
◦ Seguridad
◦ Verificabilidad
◦ Usabilidad
20
Performance
Las aplicaciones empresariales
tienen frecuentemente restricciones
de performance, por ejemplo:
◦ 1000 transacciones por segundo
◦ 3 segundos de latencia promedio para los requerimientos
Es requerido para la Performance:
◦ Métrica de cantidad de procesamiento por unidad de
tiempo
◦ Hitos que deben ser alcanzados (deadlines)
Hay muchos ejemplos de aplicaciones empresariales
con pobre performance
21
Performance - Rendimiento
“Rendimiento o Throughput, mide la cantidad de
trabajo que una aplicación debe ejecutar en una
unidad de tiempo"
◦ Transacciones por segundo
◦ Mensajes por minuto
Es requerido como:
◦ Promedio
◦ Pico
Muchos sistemas tienen requerimientos de
bajos promedio pero con altos picos de
rendimiento 22
Performance – Tiempo de respuesta
“Medida de la latencia (retardos) que una aplicación emplea en procesar un requerimiento”
Usualmente es medido en milisegundos
Es una importante métrica para los usuarios
Es requerido como:
◦ Garantizado
◦ Promedio
Por ejemplo: 95% de las respuestas en menos de 4 segundos, y todas dentro de 10 segundos
23
Performance – Hitos
“Algo que debe ser completado antes del tiempo
especificado”
Por ejemplo:
◦ El sistema de nóminas debe ser completado antes de
las 2 A.M. para poder realizar el envío a los Bancos
◦ Semanalmente la contabilidad debe estar procesada
para las 6am del lunes de tal manera que esté
disponible para la administración
Los hitos son frecuentemente asociados con
procesos batch en los sistemas
24
Escalabilidad
“Cuan bien puede una solución resolver un
problema cuando el tamaño del problema se
incrementa”
4 problemas comunes de escalabilidad:
◦ Requerimientos de carga
◦ Conexiones
◦ Tamaño de datos
◦ Despliegues
25
Escalabilidad – Carga del sistema
¿Cómo se comportará una aplicación de 100
tps cuando crece la carga simultáneamente? Por
ejemplo
◦ De 100 a 1000 requerimientos por segundo?
Solución ideal, sin capacidad de hardware
adicional
◦ Cuando la carga se incrementa, el rendimiento se
mantiene constante (ejemplo 100 tps), y el
tiempo de respuesta por requerimiento se
incrementa solo linealmente (ejemplo 10
segundos). 26
Escalabilidad – En la realidad
Escalabilidad debe ser alcanzada sin modificaciones a la arquitectura de la aplicación
La realidad es siempre diferente: ◦ Las aplicaciones exhibirán una disminución del
rendimiento y un posterior aumento en su tiempo de respuesta.
◦ El incremento de carga causa el incremento de recursos como CPU, red y memoria
◦ Cada requerimiento consume algo adicional de recursos (buffer de trabajo, bloqueos, etc) en la aplicación
Añadir mas hardware debe mejorar la performance
27
Escalabilidad - Con más hardware
28
Application
Application Application Application
Application
Scale-out: Application
replicated on different
machines
Scale-up:
Single application
instance is executed on a
multiprocessor machine
CPU
Escalabilidad – Cantidad de conexiones
Que pasa si el número simultáneo de conexiones de una aplicación se incrementa
◦ Y si cada conexión consume un recurso?
◦ Y si se excede el número máximo de conexiones?
Por ejemplo, un ISP:
◦ Cada conexión de un usuario genera un nuevo proceso
◦ La memoria virtual en cada servidor excede a 2000 usuarios
◦ Se necesita soporte para 100 mil usuarios
◦ Que pasa si hay una caída técnica… 29
Escalabilidad – Tamaño de datos
¿Cómo se comporta una aplicación cuando el tamaño de los datos se incrementa?
◦ El tamaño de la base de datos crece de 1 millón a 20 millones de registros?
◦ El algoritmo de análisis de imágenes pasa a procesar archivos de 100MB en lugar de 1MB?
Puede escalar una aplicación o los algoritmos de esta para manejar los requerimientos de incremento en tamaño de datos?
30
Escalabilidad – Despliegue
Cuál será el esfuerzo de instalar/desplegar
extensiones de la aplicación sobre la
instalación base?
◦ Instalar nuevos accesos?
◦ Instalar nuevos servidores/estaciones de usuario?
Soluciones típicas tienen mecanismos
automáticos de descarga/instalación
◦ Por ejemplo, aplicaciones descargadas desde
internet al celular
31
Confiabilidad
Confiabilidad (reliability): capacidad
del software para mantener su nivel
de rendimiento bajo condiciones conocidas por
unidad de tiempo
◦ Madurez
◦ Tolerancia a fallas
◦ Recuperación
◦ Degradación
◦ Disponibilidad
Tolerancia a fallas: habilidad para mantener un nivel
especificado de rendimiento en caso de fallas de
software o infracciones de la interfaz especificada.
32
Disponibilidad
Requerimiento clave para la
mayoría de aplicaciones de TI
Medido por la proporción del tiempo requerido
para su utilización. Por ejemplo:
◦ 100% disponibilidad durante las horas de trabajo
◦ No más de 2 horas de apagado a la semana
◦ 24x7 (100% disponibilidad)
Relacionado con la confianza en una aplicación
◦ Aplicaciones no confiables tienen una pobre
disponibilidad
33
Disponibilidad
Los períodos de pérdida de disponibilidad incluyen:
◦ Tiempo para detectar una falla
◦ Tiempo para corregir la falla
◦ Tiempo para reiniciar la aplicación
Estrategias para alta disponibilidad:
◦ Eliminar los puntos de falla
◦ Replicación y tolerante a fallas
◦ Detección automática y reinicio
Recuperabilidad (por ejemplo una base de datos)
◦ Capacidad para restablecer sus niveles de ejecución y
recuperar los datos afectados después de una falla de
aplicación o sistema
34
Seguridad
Autenticación: las aplicaciones deben verificar la identidad de los usuarios y otras aplicaciones que desean comunicarse
Autorización: una vez autenticados los usuarios y aplicaciones se debe determinar los accesos apropiados a los recursos
Encriptación: los mensajes enviados/recepcionados puede ser encriptados
Integridad: Esto asegura que el contenido del mensaje no haya sido alterado
No-repudio: el remitente de un mensaje tiene prueba de la entrega y el receptor se asegura de la identidad del remitente. Esto significa que no se puede refutar posteriormente su participación en el intercambio de mensajes.
35
Seguridad
Otros como: confiabilidad, confidencialidad,
disponibilidad y Auditoría
Enfoques de Seguridad
◦ SSL
◦ PKI
◦ JAAS
◦ Seguridad en Web Services
◦ Seguridad en el sistema operativo
◦ Seguridad en la base de datos
◦ Etc, etc.
36
Integración
Es la facilidad con que una aplicación puede
ser incorporada dentro de un escenario más
amplio
◦ Usando los componentes de una forma que el
diseñador originalmente no anticipó
Típicamente es logrado con:
◦ APIs de programación
◦ Integración de datos
37
Integración - Estrategias
Datos – exposición de los datos para que sean accedidos por otros componentes
API – servicios de lectura/escritura de datos de la aplicación a través de una Interface abstracta
Cada una tiene fortalezas y debilidades…
38
Application
Data
Third Party
Application
API
Interoperability through an API
facade
Interoperability achieved by direct
data access
Modificabilidad
Se refiere al costo del cambio:
¿Qué puede cambiar?
◦ La funcionalidad
◦ La plataforma (hardware, sistema operativo,
middleware, etc.)
◦ El entorno
◦ Los protocolos de comunicación
¿Cuándo y quién hace el cambio?
◦ En codificación o compilación / Desarrollador
◦ En tiempo de ejecución / Usuario final
◦ En tiempo de compilación / Administrador
39
Verificabilidad
Verificabilidad: se refiere a la facilidad con la que el
software puede ser hecho para demostrar sus fallas
mediante pruebas
¿Quién prueba?
◦ Desarrolladores
◦ Validadores
◦ Usuarios finales
◦ Etc.
¿Qué se prueba?
◦ Porciones de código
◦ El diseño
◦ Todo el sistema
40
Usabilidad
Usabilidad: se interesa en que tan fácil es para el
usuario cumplir una tarea deseada y el tipo de
apoyo al usuario que proporciona el sistema
Áreas de interés:
◦ Características para el aprendizaje del sistema
◦ Uso eficiente del sistema
◦ Mínimo impacto por errores
◦ Confianza y satisfacción por
parte del usuario
41
Otros atributos de calidad
Portabilidad
◦ Puede una aplicación ejecutarse fácilmente en
otra plataforma de software/hardware una vez
que ha sido desarrollada?
Soportabilidad
◦ Que tan fácil es dar soporte a una aplicación una
vez que se implemente?
42
Escenarios
Los escenarios o requerimientos de calidad,
especifican las respuestas del software a
determinados estímulos
Propuestos por el SEI
Un escenario de un atributo de calidad consiste
de:
◦ Una fuente de estímulo, quien genera el estímulo. Puede
ser interno o externo
◦ Un estímulo, una condición que afecta el sistema y que
debe ser tomada en cuenta
◦ El entorno, las condiciones en las que ocurre el estímulo
43
◦ El artefacto, es el sistema o partes de él que es estimulado
◦ La respuesta, la actividad resultante como consecuencia
del estímulo
◦ La medida de la respuesta (Métrica). Debe ser medible
para que pueda ser evaluada.
44
Escenarios
Ejemplo: Escenario de Performance
Fuente: Interna/Externa
Estímulo: Llega un evento (esporádico, periódico)
Artefacto: Sistema
Entorno: Normal - Sobrecargado
Respuestas: Se procesa el evento, se cambia el nivel de
servicio, etc.
Medición: Throughput, latencia, deadline, tasa de
datos perdidos, consumo de memoria, etc.
45
Ejemplo: Escenario de Modificabilidad
Fuente: Usuario, Desarrollador, Administrador, etc.
Estímulo:
Quiere agregar modificar/eliminar funcionalidad, capacidad,
atributo de calidad, etc.
Artefacto: Interface, plataforma, sistema
Entorno: En ejecución, en diseño, etc.
Respuestas:
Se determinan los componentes a ser modificados, se
hacen cambios sin afectar otra funcionalidad, etc.
Medición: Costos en tiempo/recursos, nro. módulos
modificados, etc.
46
Resumen
Los atributos de calidad (QAs) son parte de los requerimientos no funcionales de la aplicación
Existen muchos atributos
El arquitecto debe decidir cuales son importantes para una aplicación ◦ Entendiendo las implicancias para la aplicación
◦ Entendiendo las competencias de los requerimientos y acuerdos
Es importante definir los escenarios, métricas y realizar las pruebas de los atributos de calidad
47
¿Preguntas?
48
¿Qué atributo de calidad considera más
importante? Por qué?