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é?