AyDS - Atributos de Calidad - 2

06/04/2015
Atributos de Calidad
Atributos de Calidad Medibles y No Medibles
Clases de Cualidades
Medibles
No Medibles
Pueden ser medidos

mientras que el sistema
ejecuta
No pueden ser medidos

mientas el sistema ejecuta,
sino antes o despus
Devuelve la respuesta correcta?

Es fcil de usar?
Cunto tarda en ejecutar un
transaccin?
Un usuario no autorizado puede
vulnerar la seguridad?
Con qu frecuencia se cae o deja
de funcionar?
Cunto esfuerzo requiere su

construccin?
testeo?
integracin?
Cunto cost?
Cun fcil ser de modificar?
Arquitectura y Diseo de Sistemas 12
Lic. Ariel Trellini DCIC UNS
Cualidades del
Sistema
Aspectos relativos al
funcionamiento del sistema.
Pueden ser fehacientemente
medibles o no.
Disponibilidad
Modificabilidad
Performance
Seguridad
Cualidades
Relativas al Negocio
Aspectos del negocio que

tienen impacto en decisiones
arquitectura
Time to market
Vida til del sistema
Costo y beneficio
Plan de evolucin
Etc.
Cualidades de la
Arquitectura
Cualidades de la arquitectura
que suelen tener impacto en
otros atributos de calidad.
Integridad conceptual
Correctitud y completitud
Buildability (factibilidad de construccin)
Etc.
Cualidades Relativas al Negocio
Cualidades de la Arquitectura
Costo y Planificacin
Integridad Conceptual
Time To Market
Costos y Beneficios
Vida til Proyectada
Integracin con Sistemas Legados
Mercado Apuntado
Plan de Lanzamiento (incremental vs one-time)
Es esencial que tanto los requerimientos funcionales como las restricciones

sean satisfechos por la arquitectura.
Se utilizan evaluaciones formales para verificarlos (por ej, ATAM)
Buildability
Organizacional
El sistema se construye a partir de un numero pequeo de estructuras

arquitectnicas que interactan en un numero pequeo de formas
(predeterminadas)
Se logra tpicamente va un solo arquitecto, o un grupo de arquitectos
pequeo y coordinado
Correctitud y Completitud
Marketing
Disponibilidad de equipo adecuada

Experiencia en el dominio y tecnologas
Determina si el sistema puede ser construido con los recursos disponibles
Equipo
Conocimientos
Herramientas / Componentes
Cmo Definir Atributos de Calidad
Escenarios de Atributo de Calidad
Existen 3 problemas para definir atributos de calidad
Ejemplo: El sistema tiene que ser modificable
No es claro a qu cualidad pertenece un aspecto particular del sistema
Mecanismo que permite caracterizar/capturar aspectos

de atributos de calidad de una forma que puede ser
evaluado y utilizado en diseo
Las definiciones provistas por un atributo no son testeables
Ejemplo: Una falla del sistema es un aspecto de disponibilidad, seguridad o

usabilidad?
Cada comunidad tiene su propio vocabulario
Escenarios Generales vs Concretos

Generales
Performance: Habla de eventos arribando en el sistema

Seguridad: Habla de ataques arribando al sistema
Disponibilidad: Habla de fallas de un sistema
Usabilidad: Habla de inputs de usuario
Definicin Son independientes del sistema y,

potencialmente pueden pertenecer a
cualquier sistema.
Un requerimiento de atributo de calidad debera ser testeable y no

ambiguo. Para lograrlo, se utilizan escenarios de atributo de calidad
como una forma de caracterizarlos.
Testeabilidad
Usabilidad
Etc.
Ejemplo
Llega un requerimiento para hacer un

cambio en la funcionalidad, y el cambio
debe ser hecho en un momento particular
dentro del proceso de desarrollo y dentro
de un periodo de tiempo especfico.
Concretos
Aquellos que son especficos

al sistema en consideracin.
Llega un requerimiento para
agregar soporte a un nuevo
browser para un sistema web y el
cambio debe ser hecho en, como
mximo, 2 semanas.
06/04/2015
Atributos de Calidad Escenarios
Tcticas
Partes de un Escenario de Atributo de Calidad
Estmulo. La condicin a ser considerada cuando arriba al sistema.

Fuente de Estmulo. Es la entidad (humano, otro sistema, u otro actor) que
gener el estmulo.
Ambiente. Las condiciones sobre las que ocurre el estmulo
Artefacto. El artefacto (componente, equipo, sistema entero) que es
estimulado.
Respuesta. Define las acciones que el artefacto debera realizar como
respuesta al estmulo.
Medida de la Respuesta. La medida de la respuesta por la cual el artefacto
es evaluado.
Cmo se imparte portabilidad a un diseo? Y performance?

E interoperabilidad?
Definicin
Una tctica es una decision de diseo que influencia el control
de la respuesta de un atributo de calidad
Consideraciones
Cada tctica es una opcin de diseo. Puede haber otras
Una tctica puede ser refinada en otras
Generalmente las tcticas para un atributo de
calidad se organizan en una jerarqua.
Estmulo
Tctica para
Controlar la
Respuesta
Respuesta
Las partes de un Escenario de Atributo de Calidad

Atributos de Calidad Disponibilidad
Ejemplo: Disponibilidad
Fallas vs Defectos
Definicin
Las fallas son observables por los usuarios del Sistema, mientras que un
defecto no.
Cuando un defecto es observable por usuarios, pasa a ser una falla.
Si el Sistema puede corregir automticamente los efectos de un defecto,
entonces no se convierte en una falla
Es la probabilidad que tiene el Sistema de estar operativo

cuando se lo necesita. Se preocupa de las fallas del Sistema y
sus consecuencias asociadas:
Una falla ocurre cuando el Sistema no provee un servicio
consistente con sus especificaciones.
Dicha falla es observable por los usuarios del Sistema.
Medicin
Disponibilidad1 =
reas de Inters
Cmo se detecta la falla?

Cun frecuentemente ocurre?
Qu pasa cuando la falla ocurre?
Cunto tiempo el Sistema puede
estar fuera de operacin?
Cundo una falla puede ocurrir de

manera segura? Cmo se puede
evitar una falla?
Qu tipo de notificaciones son
necesarias cuando ocurre una falla?
Cunto tiempo toma su reparacin?
Los downtimes (fuera de servicio) planificados no son considerados en el clculo.
Ejemplo de Escenario General
Requerimientos de Disponibilidad de Ejemplo
tiempo medio de falla

tiempo medio de falla + tiempo medio de reparacin
Parte
Valores Posibles
Fuente
Interna al Sistema; externa al sistema
Estmulo
Defecto: omisin, crash, timing incorrecto, respuesta incorrecta
Artefacto
Procesadores del sistema, canales de comunicacin, almacenamiento

persistente, procesos
Ambiente
Operacin Normal, Inicio del Sistema, Modo de Reparacin

Operacin Degradada (por ej, funcionalidad limitada)
Respuesta
El Sistema detectara un evento y hara una o varias de las siguientes acciones:

Registrarlo
Notificar a quienes corresponda, incluyendo el usuario y otros sistemas
Deshabilitar las fuentes de eventos que causan el defecto o falla de acuerdo a
las reglas definidas
Quedar no disponible por un intervalo de tiempo, hasta que se repare
Continuar la operacin en Modo Degradado mientras se repara.
Medida de la
Respuesta
Intervalo de tiempo en el que el Sistema debe estar disponible

Porcentaje de disponibilidad
Tiempo para detectar la falla
Tiempo para reparar la falla
Tiempo que el Sistema puede funcionar en modo Degradado
06/04/2015
Ejemplo de Escenario Concreto
Tcticas
El heartbeat monitor determina que el servidor no responde ante

operaciones normales. El sistema le informa al operador y continua
operando sin tiempo de cadas.
Artefacto:
Proceso
Estmulo:
Servidor no
responde
Respuesta:
Ambiente:
Fuente:
Operacin Normal
Heartbeat
Monitor
Informar al
operador
Continuar la
operacin
Medida de
Respuesta:
Sin cadas
Atributos de Calidad Modificabilidad
Ejemplo: Modificabilidad
Cul es el costo de hacer un sistema ms modificable?
Definicin
Es el costo (y riesgo) que tiene realizar un cambio en el Sistema.
reas de Inters
Qu puede cambiar
(el artefacto)?
Funcionalidad
Plataforma (hw, so, middleware)
Ambiente (sistemas con los que debe interoperar)
Cualidades del Sistema (performance)
Capacidad (# usuarios, # tx)
Cundo se hace el cambio?
Quin lo hace?
Codificacin
Compilacin
Build
Configuracin
Ejecucin
Desarrollador
Administrador de Sistema
Usuario Final
El costo de introducir el/los mecanismo/s para hacer el sistema ms

modificable
El costo de hacer la modificacin usando el/los mecanismo/s
Sin mecanismo
Con mecanismo
Costo de Introducir el
mecanismo
Cero
Costo de crear el mecanismo
Costo de hacer la modificacin
El costo de cambiar el cdigo

fuente y testearlo
Costo de usar el mecanismo para

hacer el cambio y testear el cambio
Para N modificaciones similares, una justificacin simplificada para la creacin

de un mecanismo de cambios podra ser:
N x Costo de hacer el
cambio sin el mecanismo
=>
Costo de crear el mecanismo

+ (N x Costo de hacer el cambio usando el mecanismo)
Cul es la probabilidad de cambio

* N es la cantidad de modificaciones del mismo tipo que se preven (una prediccin)
Parte
Valores Posibles
Fuente
[Quin hace el cambio] Usuario final, desarrollador, administrador del sistema
Estmulo
[Qu cambio debe hacerse] Deseo de agregar/modificar/eliminar funcionalidad,

atributos de calidad, etc.
Artefacto
[Qu tiene que cambiar] UI del sistema, plataforma, ambiente, sistemas con los
que interacta
Ambiente
[Cundo se hace el cambio] Ejecucin, compilacin, build, diseo
Respuesta
Medida de la
Respuesta
Costo del cambio en trminos de:

Elementos afectados
Esfuerzo
Dinero
Grado en que afecta a otras caractersticas del sistema.
Un desarrollador desea cambiar la interfaz de usuario para que el

color de fondo de la pantalla sea azul. El cambio se realizar sobre el
cdigo en tiempo de diseo, debiendo tomar no ms de 3 horas en
realizarlo y testearlo y sin tener efectos colaterales sobre el
comportamiento del sistema.
Localizar los lugares a ser modificados

Realizar las modificaciones sin afectar otras caractersticas del sistema
Testear las modificaciones
Instalar modificaciones
Artefacto:
Estmulo:
Fuente:
Desea
modificar la
UI
Desarrollador
Cdigo
Ambiente:
En tiempo de
diseo
Respuesta:
La modificacin es
hecha sin efectos
colaterales
Medida de
Respuesta:
3 horas
06/04/2015
Tcticas
Se basan en 4 variables
Tamao del un mdulo

Siempre y cuando el criterio para dividir el mdulo refleje el tipo de cambio que es
probable de ocurrir
Acoplamiento
Reducir el acoplamiento entre dos mdulos A y B disminuir el costo esperado de
cualquier modificacin que afecte a uno de esos mdulos.
Cohesin
Si un mdulo tiene una baja cohesin, puede ser mejorada eliminando
responsabilidad no afectadas por los cambios previstos. As se reduce la posibilidad
de efectos colaterales.
Momento de implementacin (binding time)

En una arquitectura que propicia modificaciones tardas en el ciclo de vida, en
promedio, un cambio costar menos que en una arquitectura que fuerza que la
misma modificacin sea hecha ms temprano.
Atributos de Calidad Performance
Ejemplo: Performance
Definicin
Se ocupa bsicamente de cunto tiempo le toma al Sistema
responder cuando ocurre un evento.
Consideraciones
Origen de eventos
De usuarios
De otros sistemas
Del mismo sistema
Patrn de arribo del eventos
Variable a evaluar
Peridico
Estocstico
Espordico
Latencia
Momento de procesamiento
Throughput
Varianza de la latencia
Cantidad de eventos no procesados por exceso de carga
Datos perdidos por exceso de carga
Parte
Valores Posibles
Fuente
Una de un nmero independiente de fuentes posibles
Estmulo
Eventos peridicos arriban

Eventos estocsticos arriban
Eventos espordicos arriban
Artefacto
El sistema, uno de sus componentes, un conjunto de componentes
Ambiente
Modo normal
Modo sobrecargado
Modo emergencia
Respuesta
Procesar el estmulo
Cambiar el nivel de servicio
Medida de la
Respuesta
Latencia
Deadline,
Throughput
Varianza de latencia
Tasa de prdida de requerimientos
Tasa de prdida de datos.
Tcticas
Bajo una operacin normal del sistema, las transacciones ejecutadas

por los usuarios deberan resolverse, en promedio, en 2 segundos.
Background
Tiempo de Procesamiento
Los eventos son manejados por la ejecucin de uno o ms componentes, cuyo
tiempo utilizado es un recurso.
Contencin de Recursos
Muchos recursos pueden ser usados por un nico cliente a la vez. Otros clientes
deben esperar para acceder a ese recurso.
Estmulo:
Instanciar
Transacciones
Fuente:
Usuarios
Sistema
Ambiente:
Bajo operacin
normal
Tiempo de Bloqueo
Un cmputo puede estar bloqueado debido a contencin sobre otro recurso, ya que
el recurso no est disponible, o a que el cmputo depende del resultado de otro
cmputo que aun no est disponible.
Artefacto:
Respuesta:
Transacciones
procesadas
Medida de
Respuesta:
Latencia
promedio de 2
segundos
Disponibilidad de Recursos
Un cmputo podra estar detenido debido a la no disponibilidad de un recurso:
porque el recursos est offline, o porque est atravesando una falla.
Dependencia sobre otros cmputos

Un cmputo puede tener que esperar porque debe sincronizarse con el resultado
de otro cmputo
06/04/2015
Ejemplo: Seguridad
Definicin
Es una medida de la capacidad que tiene un Sistema para
resistir el uso no autorizado mientras continua proveyendo
servicio a usuarios legtimos
Consideraciones
Tipos de ataque
Acceder a datos/servicios a los que el usuario no est autorizado

Limitar el servicio a usuarios legtimos
La seguridad puede ser caracterizada en trminos de:

Confidencialidad
Integridad
Disponibilidad
Atributos de Calidad Seguridad
Parte
Valores Posibles
Fuente
Individuo o sistema que est
Autenticacin
No repudiacin
Autorizacin
Un empleado descontento desde una ubicacin remota intenta

acceder a la tabla de tasas de pago durante la operacin normal. El
sistema mantiene un registro de auditora y los datos correctos son
restaurados dentro de 1 da.
correctamente identificado, incorrectamente identificado, de identidad desconocida
que es
Interno/externo, autorizado/no autorizado
con acceso a.
Recursos limitados, vastos recursos
Estmulo
Trata de
Artefacto
Servicios del sistema; datos dentro del sistema
Ambiente
Online u offline; conectado o desconectado; detrs de un firewall o abierto
Ver datos, modificar/eliminar datos, acceder a servicios del sistema, reducir la

disponibilidad de los servicios del sistema
Respuesta
Medida de la
Respuesta
Artefacto:
Estmulo:
Autentica al usuario; oculta la identidad del usuario; bloquea/permite accesos a datos y/o
servicios; garantiza o rechaza permisos para acceder a datos y/o servicios; registra los
accesos por usuario; almacena datos en un formato no legible; reconoce un inexplicable
aumento de demanda del servicio, informando a un usuario u otro sistema y restringiendo la
disponibilidad del servicio.
Fuente:
Empleado
descontento
conectado
remotamente
Tiempo/esfuerzo/recursos necesarios para sortear medidas de seguridad con probabilidad

de xito; probabilidad de detectar ataques; probabilidad de identificar responsables de un
ataque o del acceso/modificacin de datos; porcentaje de servicio aun disponible ante un
ataque denial-of-services.
Intenta
modificar
tasas de pago
Datos dentro
del Sistema
Ambiente:
Bajo operacin
normal
Respuesta:
El Sistema
mantiene registros
de auditora
Medida de
Respuesta:
Los datos correctos
son restaurados
dentro de 1 da y el
autor es identificado
Ejemplo: Testeabilidad
Tcticas
Definicin
Es el grado en el cual un artefacto de software (sistema,
modulo, clase, etc) soporta testing en un contexto de test dado.
Si la testeabilidad del arterfacto de sw es alta, entonces
encontrar defectos a travs del testing es ms sencillo.
Consideraciones
Se orienta, principalmente, a la posibilidad de realizar tests automatizados:

unit tests, integration tests, UI tests.
Para que un artefacto de software sea testeable, debe ser posible
Controlar las entradas del componente, ejercitando su estado interno.

Observar las salidas
06/04/2015
Atributos de Calidad Testeabilidad
Parte
Valores Posibles
Fuente
Testers unitarios; testers de integracin, tester de sistema, tester de aceptacin,

usuario finales del sistema (ya sea de manera manual o automtica)
Estmulo
Un conjunto de tests es ejecutado debido a:

Incremento de cdigo terminado o integracin de subsistema terminada
Sistema entregado
Artefacto
La porcin del sistema siendo testeada
Ambiente
Respuesta
Ejecutar un conjunto de tests y capturar el resultado

Capturar las actividades que resultaron en una falla.
Controlar y monitorear el estado del sistema
Medida de la
Respuesta
Un tester unitario (desarrollador) termin una unidad de cdigo

durante el desarrollo y realiza una secuencia de tests cuyos resultados
son capturados logrando una cobertura del 85% en menos de 3
horas.
En tiempo de desarrollo
En tiempo de compilacin
En tiempo de deployment
En tiempo de ejecucin
Artefacto:
Estmulo:
Unidad de
cdigo
terminada
Fuente:
Unidad de
cdigp
Ambiente:
Respuesta:
Resultados
capturados
Desarrollo
Tester Unitario
Tcticas
Caso de Estudio: El Ejrcito de Simios de Netflix
Chaos Monkey: Aleatoriamente mata procesos en el sistema ejecutando para

monitorear el efecto de un proceso fallido.
Latency Monkey: Introduce retardos artificiales en la capa de comunicacin
cliente-servidor para simular degradacin.
Conformity Monkey: Busca instancias que no adhieren a las buenas prcticas y
las baja (por ej., instancias que no pertenecen a un auto-scaling group).
Doctor Monkey: Monitorea la salud de las instancias de EC2.
Janitor Monkey: Asegura que en ambiente de Netflix en la nube no desperdicia
recursos. Donde encuentra un recurso no usado, lo libera.
Security Monkey: Busca violaciones o vulnerabilidades de seguridad. Si las
encuentra, las elimina. Tambin chequea que los certificados SSL no se venzan.
10-18 Monkey: Detecta problemas de configuracin de localizacin e i18n.
Netflix pondera la testeabilidad de su sistema para asegurar la calidad de su

servicio.
Atributos de Calidad Usabilidad
Ejemplo: Usabilidad
Definicin
La facilidad con que las personas pueden utilizar un Sistema con
el fin de alcanzar un objetivo concreto.
Parte
Fuente
Estmulo
Aprendizaje de caractersticas del sistema

Uso eficiente del sistema
Minimizar el impacto de errores
Adaptacin del sistema a las necesidades del usuario
Incrementar la confianza y satisfaccin
Sistema
En tiempo de ejecucin; en tiempo de configuracin
Para soportar el aprendizaje de las caractersticas del sistema
Sistema de ayuda sensible al contexto; UI familiar para el usuario
Agregacin de datos/comandos; reuso de datos y comandos ya ingresados; soporte
para una navegacin eficiente; distintas vistas con operaciones consistentes;
Para minimizar el impacto de errores de usuario

Deshacer, rehacer y recuperarse de una falla del sistema; reconocer y corregir un error
de usuario; recuperar password olvidada
Para adaptar el sistema

Personalizacin; Internacionalizacin
Para sentirse cmodo
Muchas caractersticas de usabilidad requieren de soluciones

arquitectnicas tempranas
Valores Posibles
Usuario final
Quiere
Para soportar el uso del sistema eficientemente
Relacin con la Arquitectura
Aprender las caractersticas del sistema; usar el sistema eficientemente; minimizar el

impacto de errores de usuario; adaptar el sistema a sus necesidades; configurar el sistema
Artefacto
Ambiente
Respuesta
Areas de Inters
Netfix est montado sobre la nube de Amazon (AWS), ms precisamente

sobre instancias de EC2 (servidores virtuales).
Utiliza un ejrcito de simios como para parte de su proceso de testing.
Medida de
Respuesta:
La cobertura de
cdigo del 85% es
realizada en 3 horas.
Porcentaje de cobertura del cdigo ejecutable

Probabilidad de falla, si la falla existe
Tiempo para realizar los test
Longitud de la cadena de dependencias ms larga en un test
Cantidad de tiempo para preparar un ambiente de test
Mostrar el estado del sistema; trabajar al ritmo del usuario
Medida de la
Respuesta
Tiempo de la tarea; cantidad de errores; cantidad de problemas resueltos;

satisfaccin del usuario; tasa de operaciones exitosas vs operaciones no exitosas;
interaccin necesaria para completar una tarea.
06/04/2015
Tcticas
Un usuario descarga una nueva aplicacin y est usndola

productivamente luego de 2 minutos de experimentacin.
Artefacto:
Sistema
Estmulo:
Fuente:
Descargar una
nueva
aplicacin
Respuesta:
Ambiente:
El usuario usa la
aplicacin
productivamente
En ejecucin
Usuarios
Medida de
Respuesta:
Dentro de 2 minutos
de exploracin
Atributos de Calidad Confiabilidad
Ejemplo: Confiabilidad
Observaciones:
Definicin
La capacidad de un sistema de mantenerse operativo en el

tiempo.
La probabilidad que tiene el sistema de realizar su funcin sin
fallas durante un perodo de tiempo
Est muy ligado a otros atributos de calidad:
Medidas:
Tiempo Medio Entre Fallas (MTTF)

Porcentaje de operaciones que se ejecutan correctamente en un periodo
Disponiblidad: Es la probabilidad que tiene el Sistema de estar operativo en un

determinado punto en el tiempo.
Tolereancia a Fallas: La capacidad para mantener un determinado nivel de
rendimiento en casos de fallas de software o de violacin a su interfaz.
Recuperabilidad: La capacidad de restablecer un nivel de rendimiento
determinado y recuperar los datos directamente afectados en caso de falla.
Madurez: La capacidad de evitar fallas como resultado de defectos en el
software.
Ejemplo: Sistema de Aterrizaje Automtico
Disponibilidad Alta: Debe estar disponible cuando el avin debe aterrizar

Confiabilidad Baja: No tiene que permanecer operativo por largos periodos
de tiempo.
Atributos de Calidad Confiabilidad
Parte
Valores Posibles
Fuente
Interna al Sistema; externa al sistema
Estmulo
Defecto: datos errneos, falla de hardware, bug en el cdigo, problemas de

ambiente
Artefacto
Procesadores del sistema, canales de comunicacin, almacenamiento

persistente, procesos, datos
Ambiente
Modo Normal, Modo Sobrecargado
Respuesta
El Sistema detectara un evento y hara una o varias de las siguientes acciones:

Registrarlo
Notificar a quienes corresponda, incluyendo el usuario y otros sistemas
Tomar las acciones necesarias para dejar los datos consistentes
Reintentar la operacin (probablemente con algn delay)
Medida de la
Respuesta
Tiempo medio entre fallas

Porcentaje de operaciones que se ejecutan correctamente en un periodo
Tiempo que el Sistema puede funcionar en modo Sobrecargado
En AWS (la nube de Amazon) las conexiones a los servicios de AWS

pueden fallar eventual y espordicamente. Ante una falla de la
infraestructura de AWS, el sistema debe reintentar la transaccin en
5, 10, 20, 40... segundos hasta que logre ejecutarse existosamente.
Artefacto:
Fuente:
Infraestructura
de AWS
Estmulo:
Proceso
Error de
acceso a un
servicio de
AWS
Ambiente:
Operacin Normal
Respuesta:
Reintentar la
transaccin
hasta tener
xito.
Frecuencia de
reintento: 5,
10, 20, 40
segundos,
Medida de
Respuesta:
Sin
transacciones
fallidas
06/04/2015
Tcticas
Reliability Tactics
Detect Faults
Prevent Faults
Reintroduction
Active Redundancy
Shadow
Transaction
Passive
Redundancy
State Resync
Predective Model
Heartbeat
Escalating Restart
Timestamp
Exception Handling
Exception
Prevention
Sanity Checking
Rollback
Ping/Echo
Fault
Recover from Faults
Preparation and
Repair
Monitor
Condition
Monitoring
Voting
Retry
Ignore Faulty
Behaior
Increase
Competence Set
Replace
Degradation
Exception
Detection
Reconfiguration
Self-Test
Async. Processing
Non-Stop
Forwarding
Fault
Masked
or Repair
Made

AyDS - Atributos de Calidad - 2

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AyDS - Atributos de Calidad - 2

Transféré par

Droits d'auteur :

Formats disponibles

06/04/2015

Atributos de Calidad Medibles y No Medibles

Pueden ser medidos

No pueden ser medidos

Devuelve la respuesta correcta?

Cunto esfuerzo requiere su

Arquitectura y Diseo de Sistemas 12

Lic. Ariel Trellini DCIC UNS

Aspectos del negocio que

Arquitectura y Diseo de Sistemas 13

Lic. Ariel Trellini DCIC UNS

Cualidades Relativas al Negocio

Es esencial que tanto los requerimientos funcionales como las restricciones

El sistema se construye a partir de un numero pequeo de estructuras

Disponibilidad de equipo adecuada

Determina si el sistema puede ser construido con los recursos disponibles

Arquitectura y Diseo de Sistemas 14

Lic. Ariel Trellini DCIC UNS

Arquitectura y Diseo de Sistemas 15

Lic. Ariel Trellini DCIC UNS

Cmo Definir Atributos de Calidad

Escenarios de Atributo de Calidad

Existen 3 problemas para definir atributos de calidad

Ejemplo: El sistema tiene que ser modificable

No es claro a qu cualidad pertenece un aspecto particular del sistema

Mecanismo que permite caracterizar/capturar aspectos

Las definiciones provistas por un atributo no son testeables

Ejemplo: Una falla del sistema es un aspecto de disponibilidad, seguridad o

Cada comunidad tiene su propio vocabulario

Escenarios Generales vs Concretos

Performance: Habla de eventos arribando en el sistema

Definicin Son independientes del sistema y,

Un requerimiento de atributo de calidad debera ser testeable y no

Lic. Ariel Trellini DCIC UNS

Llega un requerimiento para hacer un

Arquitectura y Diseo de Sistemas 17

Aquellos que son especficos

Atributos de Calidad Escenarios

Partes de un Escenario de Atributo de Calidad

Estmulo. La condicin a ser considerada cuando arriba al sistema.

Cmo se imparte portabilidad a un diseo? Y performance?

Las partes de un Escenario de Atributo de Calidad

Lic. Ariel Trellini DCIC UNS

Arquitectura y Diseo de Sistemas 19

Atributos de Calidad Disponibilidad

Es la probabilidad que tiene el Sistema de estar operativo

Lic. Ariel Trellini DCIC UNS

Cmo se detecta la falla?

Cundo una falla puede ocurrir de

Arquitectura y Diseo de Sistemas 20

Lic. Ariel Trellini DCIC UNS

Atributos de Calidad Disponibilidad

Los downtimes (fuera de servicio) planificados no son considerados en el clculo.

Arquitectura y Diseo de Sistemas 21

Lic. Ariel Trellini DCIC UNS

Atributos de Calidad Disponibilidad

Ejemplo de Escenario General

Requerimientos de Disponibilidad de Ejemplo

Arquitectura y Diseo de Sistemas 22

tiempo medio de falla

Lic. Ariel Trellini DCIC UNS

Interna al Sistema; externa al sistema