ENTENDER LOS ATRIBUTOS DE CALIDAD

-Influyen factores internos externos, comerciales, tecnológicos. Que cumplan ciertas características.
-Generan aspectos no visibles de la arquitectura.
-Aborda ciertas características para que cumpla esa calidad de SW. Este Atributo Calidad hace que sea una
propiedad medible, comprobable para lo que se plantea. E indica cuanto satisface la necesidad de los
requerimientos.
-Como expresaremos
-Como podemos lograr esa calidad
-Como podemos especificar que redireccione al producto

ARQUITECTURA Y REQUERIMIENTOS
-Req funcionales: Que db hacer el sistema y como debe comportarse. Implementados por el cliente. Indica
como debe comportarse el sistema para cumplir el objetivo.
-Req atributos de calidad: Califican los Req funcionales de una manera global, lo que dará mas entendimiento
de la grado de certeza que tiene el sistema en cuanto a los estímulos(Errores).
-Req Restricciones: No podemos omitirlos. Ciertas características de diseño ya han sido establecidos. Dependen
del entorno en que están para su implementacion.

RESPUESTA
“Todo esto genera una respuesta” que satisface ciertos criterios
-Funcionales: Satisfacen mediante la asignación de secuencia de responsabilidades.
-Atributos de calidad: Satisfacen ciertas estructuras de diseño de la Archi y comportamiento. Y medir si el
funcionamiento es el adecuado para soportar los estímulos que lo genera.
-Restricciones: Satisface a ciertas decisiones al diseño planteado. O sea adecuar al diseño anterior y
complementar con el diseño que implementaremos. Y medir el estimulo que se generara.

FUNCIONALIDAD
-Tiene que realizar ciertas operaciones las cuales han sido implementadas, se relacionan fuertemente con la
arquitectura
-No se plantea directo la arquitectura aunque hayan muchas funcionalidades.
-Estas funcionalidades las estructuramos en elementos, módulos, clases, servicios, capas, DB, App. Que sean
medibles
-La responsabilidad de cada uno, la archi hace cumplir las restricciones con respecto a los requerimientos del
cliente

CONSIDERACIONES DE ATRIBUTOS DE CALIDAD

-Proporcionan los atributos de calidad, para modificar, extender, propenso a estímulos.
-Estan enfocados de forma particular a que atributo de calidad se planteara. Y así plantear una sola idea, para
que todo el equipo lo entienda. Seguridad “Ataques”, “Fallas”
-La solución cae en categorizar los QA en 2 categorias:
-Describir algunas propiedades del sistema en tiempo de ejecución
-Describir propiedades del sistema que sean modificables y testeables
-Los sistemas complejos
- Los QA ayudan a que la arquitectura que plantearemos no genere problemas a futuro, a ciertos factores
externos que se presenten

ESPECIFICANDO LOS REQUERIMIETOS DE QA

-Deben ser de forma comprobable e inequívoca. Medibles testealbles sin abstracción.
Se los itentifican con
-Estimulo: Sistema externo, user, cualquier entorno que pueda estimular al sistema. De que forma validaremos.
Una vez identificado el sistema responde
-Fuente del estimulo: Debe generarse y afrontar controlándolo. Con validaciones.
-Respuesta: nos indicara como actúa frente al estimulo.
-Respuesta medible: Pros contras de requerimientos y tomar ciertas decisiones. Así atacamos esto.
-Entorno: Circunstancias que se ejecuta en dicho escenario dependiendo los atributos que seleccionemos
-Artefacto: Validar el estimulo.

Identificaremos en
-Escenarios Gral
-Escenarios concretos
Donde atacaremos ciertas partes del sistema
TACTICAS PARA LOGRAR LOS QA
-Los requisitos especifican una respuesta que da el sistema. Las pruebas tienen que ser a un determinado área
de diseño.
-Consiste en una colección de decisiones. Que se enfocan en el estimulo donde la respuesta tiene que ser
enfocada al estimulo como tal
1.- Patrones de diseño complejos: ayudan a mejores diseños en la decisión. Elegir patrones de diseño
2.- Una vez terminado el diseño se puede analizar que otros QA se puede añadir. Y así poner en producción y
probar si el cliente esta satisfecho.
3.- Mide la calidad de respuesta de la arquitectura que planteamos. Los hace visibles para un mejor
entendimiento.

GUIA DE DESICIONES DE QA
-Asignacion de responsabilidades:
-Identificar la importancia de Responsabilidades
-
-Modelo de coordinación
-Modelo de datos
-Gestion de recursos
-Mapeo de los diferentes elementos de Archi
-Eleccion de tecnología
La disponibilidad se refiere a la capacidad del sistema para estar disponible para su uso, especialmente después
de que ocurra una falla. La falla debe reconocerse (o prevenirse) y luego el sistema debe responder de alguna
manera. La respuesta deseada dependerá de la criticidad de la aplicación y del tipo de falla y puede ir desde
“ignorarla” hasta “continuar como si no hubiera ocurrido”.
Las tácticas para la disponibilidad se clasifican en detectar fallas, recuperarse de fallas y prevenir fallas. Las
tácticas de detección dependen, esencialmente, de detectar signos de vida de varios componentes. Las tácticas
de recuperación son una combinación de volver a intentar una operación o mantener datos o cálculos
redundantes. Las tácticas de prevención dependen de la eliminación de elementos del servicio o de la
utilización de mecanismos para limitar el alcance de las fallas.

La interoperabilidad se refiere a la capacidad de los sistemas para intercambiar información de manera útil.
Estos sistemas pueden haber sido construidos con la intención de intercambiar información, pueden ser
sistemas existentes que se desea intercambiar información, o pueden brindar servicios generales sin conocer
los detalles de los sistemas que desean utilizar esos servicios.
El escenario general de interoperabilidad proporciona los detalles de estos diferentes casos. En cualquier caso
de interoperabilidad, el objetivo es intercambiar información intencionalmente o rechazar la solicitud de
intercambio de información.
Lograr la interoperabilidad implica que los sistemas relevantes se localicen entre sí y luego gestionen las
interfaces para que puedan intercambiar información.
La modificabilidad se ocupa del cambio y el costo en tiempo o dinero de realizar un cambio, incluida la medida
en que esta modificación afecta otras funciones o atributos de calidad.
Los desarrolladores, los instaladores o los usuarios finales pueden realizar cambios, y estos cambios deben
estar preparados. Hay un costo de preparación para el cambio, así como un costo de hacer un cambio. Las
tácticas de modificabilidad están diseñadas para prepararse para cambios posteriores.
Las tácticas para reducir el costo de realizar un cambio incluyen hacer módulos más pequeños, aumentar la
cohesión y reducir el acoplamiento. Aplazar la vinculación también reducirá el costo de realizar un cambio.
La reducción del acoplamiento es una categoría estándar de tácticas que incluye la encapsulación, el uso de un
intermediario, la restricción de dependencias, la ubicación conjunta de responsabilidades relacionadas, la
refactorización y la abstracción de servicios comunes.
Aumentar la cohesión es otra táctica estándar que implica separar responsabilidades que no tienen el mismo
propósito.
Aplazar el enlace es una categoría de tácticas que afectan el tiempo de compilación, el tiempo de carga, el
tiempo de inicialización o el tiempo de ejecución.

El rendimiento se trata de la gestión de los recursos del sistema frente a tipos particulares de demanda para
lograr un comportamiento de tiempo aceptable. El rendimiento se puede medir en términos de rendimiento y
latencia para sistemas en tiempo real interactivos e integrados, aunque el rendimiento suele ser más
importante en los sistemas interactivos y la latencia es más importante en los sistemas integrados.
El rendimiento se puede mejorar reduciendo la demanda o gestionando los recursos de forma más adecuada.
Reducir la demanda tendrá el efecto secundario de reducir la fidelidad o negarse a atender algunas solicitudes.
La gestión de los recursos de forma más adecuada se puede realizar mediante la programación, la replicación o
simplemente aumentando los recursos disponibles.
Los ataques contra un sistema se pueden caracterizar como ataques contra la confidencialidad, integridad o disponibilidad
de un sistema o sus datos. La confidencialidad significa mantener los datos fuera del alcance de aquellos que no deberían
tener acceso y otorgar acceso a aquellos que deberían hacerlo. Integridad significa que no hay modificaciones no
autorizadas o eliminación de datos, y disponibilidad significa que el sistema es accesible para quienes tienen derecho a
usarlo.
El énfasis en distinguir varias clases de actores en la caracterización conduce a muchas de las tácticas utilizadas para lograr
la seguridad. Identificar, autenticar y autorizar a los actores son tácticas destinadas a determinar qué usuarios o sistemas
tienen derecho a qué tipo de acceso a un sistema.
Se supone que ninguna táctica de seguridad es infalible y que los sistemas se verán comprometidos. Por lo tanto, existen
tácticas para detectar un ataque, limitar la propagación de cualquier ataque y reaccionar y recuperarse de un ataque.
La recuperación de un ataque involucra muchas de las mismas tácticas que la disponibilidad y, en general, implica devolver
el sistema a un estado consistente antes de cualquier ataque.

Asegurar que un sistema sea fácilmente comprobable tiene beneficios tanto en términos del costo de las pruebas como de
la confiabilidad del sistema. Un vehículo que se utiliza a menudo para ejecutar las pruebas es el arnés de prueba. Los
arneses de prueba son sistemas de software que encapsulan recursos de prueba, como casos de prueba e infraestructura
de prueba, de modo que es fácil volver a aplicar pruebas en iteraciones y es fácil aplicar la infraestructura de prueba a
nuevos incrementos del sistema. Otro vehículo es la creación de casos de prueba previos al desarrollo de un componente,
para que los desarrolladores sepan qué pruebas debe pasar su componente.
Controlar y observar el estado del sistema es una clase importante de tácticas de comprobación. Brindar la capacidad de
inyectar fallas, registrar el estado del sistema en partes clave del sistema, aislar el sistema de su entorno y abstraer varios
recursos son tácticas diferentes para respaldar el control y la observación de un sistema y sus componentes.
Los sistemas complejos son difíciles de probar debido al gran espacio de estados en el que se realizan sus cálculos y al
mayor número de interconexiones entre los elementos del sistema. En consecuencia, mantener el sistema simple es otra
clase de táctica que respalda la capacidad de prueba.
El soporte arquitectónico para la usabilidad implica permitir que el usuario tome la iniciativa, en circunstancias
tales como cancelar un comando de ejecución prolongada o deshacer
un comando completo—y la agregación de datos y comandos.
Para poder predecir las respuestas del usuario o del sistema, el sistema debe mantener un modelo explícito del
usuario, el sistema y la tarea.
Existe una fuerte relación entre apoyar el diseño de la interfaz de usuario
proceso y modificabilidad de apoyo; esta relación es promovida por patrones que
hacer cumplir la separación de la interfaz de usuario del resto del sistema, como el patrón MVC.
Other Quality Attributes
Besides the quality attributes we’ve covered in depth, some others that arise frequently are variability,
portability, development distributability, scalability and elasticity, deployability, mobility, and monitorability