Está en la página 1de 22

Arquitectura de

Software

ATRIBUTOS DE CALIDAD, ESCENARIOS Y TÁCTICAS

Felipe Romero
Mary Luz Marin
Edward Aldana
Alejandro Linares
Jonatán Rincón
David Soriano
Escenarios de calidad
 Escenarios de Atributos de calidad

 Para resolver el problema de especificar los atributos de calidad y


vincularlos con cada aspecto del problema en común, se utilizan los
escenarios de atributos de calidad. Partes de la especificación:

 Fuente del estímulo: entidad que lo genera.


 Estímulo: condición que necesita ser considerada cuando llega al
sistema.
 Entorno: condiciones dentro de las cuales se presenta el estímulo.
 Artefacto: parte del sistema que recibe el estímulo.
 Respuesta: actividad que ocurre luego de la llegada del estímulo.
 Medida de la Respuesta: criterio para testear el requerimiento.

 Los escenarios pueden ser generales, es decir, independientes del
sistema, o concretos, cuando son específicos de un sistema particular
en estudio. Los escenarios concretos son casos particulares de los
escenarios generales. La caracterización de un atributo estará dada por
un conjunto de escenarios generales, que deberán transformarse en
escenarios específicos para el sistema en estudio.
 Un conjunto de escenarios concretos puede ser utilizado como la
especificación de los requerimientos de calidad del sistema.

Ejemplo de escenarios de calidad

Cambiar el Modelo de cobro


modelo de cobro reemplazado 1
SGT 2
3
4

Departamento
de Marketing Desarrollo/Evolución Tiempo < 2 semanas
Esfuerzo < 3 personas/mes

Nombre: Modificabilidad: Cambio en la lógica de cobro


Resumen : La organización desarrolladora piensa proveer la misma solución a
otras empresas municipales. Es necesario que la misma solución, en el mismo
contexto, soporte cambios en su lógica de cobro.
PERFORMANCE

lleva a cabo una funcionalidad especifica dada una restricción de velocidad, prec

Patrones de Arribos (Eventos)


ü Puede ser periódico, probabilística o esporádico.
ü Dependiendo lo que se mide no importa la cantidad de
usuarios sino los pedidos o transacciones.
 Patrones de Respuesta
ü Latencia. Puede ser medido por el tiempo que tarde el
sistema en responder
ü La cantidad de tx que el sistema puede responder
ü Números de Eventos no procesados y la cantidad de
 información perdida por que el sistema no puede
responder
ü
 Un ejemplo de Performance

 Los usuarios inician 1.000 transacciones X, por minuto


 bajo condiciones normales, de 9 a 18:00hs, el sistema
debe procesarlas en una latencia menor a 3 segundos.
 ELEMENTO  DESCRIPCION

Origen del estimulo  Definir el tipo de Usuarios


 

Estimulo  1.000 tx por minuto




Ambiente  Carga normal


 

 Todo el sistema
Componentes 

 

Respuesta  Transacción procesada




Medida de la respuesta  La latencia debe ser menor a 3


segundos

SEGURIDAD

 Es la medida sobre la habilidad del sistema


para
 resistir usos no autorizados mientras sigue
 proveyendo sus servicios a los usuarios
legítimos.
 Cuando se quiere romper la seguridad, es un
ataque que puede intentar acceder a datos y
modificarlos, o a servicios, y como conclusión
muchas veces denegar los servicios a los usuarios.

Características
 No Repudio
 Confidencialidad

 Integridad

 Aseguramiento

 Disponibilidad

 Auditoria
 Si el administrador de accesos (seguridad)
realiza, agrega o quita algún rol a cualquier
usuario, estos cambio deben ser reflejados de
manera inmediata en la sesión del usuario a la cual
se le modificaron los accesos”
Testability


 Es el grado de facilidad que
tiene un sistema para ser
probada en su completitud, ya
sea unitariamente, integración,
aceptación y regresión”


 El 40% del costo de un proyecto es consumido por
el testing(Prueba)

 Cuanto mejor podamos acelerar y completar las


tareas de testeo, tendería a minimizar el costo y
los tiempos de testeo.

 Es importar tener en cuenta que decisiones


arquitectónicas pueden lograr bajar los tiempos
de testeo, pero hay que tener en cuanta la
complejidad y lo que impacta esa decisión en la
construcción


¿QUE ES USABILIDAD?
USABILIDAD
Podemos definir la

usabilidad como la
medida en la cual
un producto puede
ser usado por
usuarios específicos
para conseguir
objetivos específicos
con efectividad,
eficiencia y
satisfacción en un
contexto de uso
especificado.
AREAS

 –Aprendizaje
–Uso eficiente

–Minimizar el impacto de los errores

–Adaptabilidad

–Incrementar la satisfacción del

usuario.
Areas de aprendizaje
areas de uso eficiente
Minimizar el impacto de los errores
Adaptabilidad
Incrementar la satisfacción del usuario
USABILIDAD EN UN CASO DE USO
Si bien este atributo de calidad es
principalmente definido y
especificado o en los
casos de uso o en la especificación

de la User
Interface, existen operaciones y

features que sí
o sí deben ser implementadas por la

Arquitectura, como el caso proveer

la posibilidad
de cancelar operaciones que están

siendo
procesadas, otro caso interesante

de analizar es
el de deshacer una acción ejecutada

y
procesada.