Está en la página 1de 43

Atributos de Calidad y

Atributos de Calidad y
T
T

cticas
cticas
Performance / Disponibilidad / Seguridad / Usabilidad / Modificabilidad
Atributos, concerns y tcticas
Una breve introduccin
3
Arquitecturas de Software Arquitecturas de Software
Concerns
Concerns
y Escenarios
y Escenarios
4
Arquitecturas de Software Arquitecturas de Software
T
T

cticas
cticas
Se asocian con los concerns y
escenarios.
Identifico las decisiones que tomo
sobre la arquitectura sobre los
escenarios.
Ayudan en vincular atributos de calidad
contra decisiones de arquitectura en pos
de mejorar el tradeoff analysis.
Particulares de cada concern.
Performance
About prediction of response time
6
Arquitecturas de Software Arquitecturas de Software
Atributos de Calidad
Atributos de Calidad
Performance ( y escalabilidad) :
Lahabilidaddelsistemaparaejecutarenforma
predecibledentrodelperfildeperformance definido(yla
capacidadparaprocesarvolumenincrementadosde
carga)
Concerns
Tiempo de respuesta
Latencias y throughputs
Picos de carga
Cuellos de botella
7
Arquitecturas de Software Arquitecturas de Software
la oficina de ventas requiere conocer el
dinero disponible en banco y realizar una
prediccin del dinero que ser depositado
la central requiere emitir un reporte que
indica el dinero disponible estimado El
tiempo de respuesta esperado para la
emisin de este reporte no debe superar los
dos minutos
Ejemplo response time: no debe superar los dos
minutos.
8
Arquitecturas de Software Arquitecturas de Software
La entrega se realiza a los 25 cajeros en
promedio dentro de una ventana de tiempo
que no debe superar 30 minutos Esta
actividad presenta tres ventanas entre las
7.30 y 8.00 hs, 10.30 y 11 hs y 14.30 y
15.00 hs.
Ejemplo peak load:1200 tiendas, que dentro de las
tres ventanas generan cada una 25 transacciones
dentro de los 30 minutos.
9
Arquitecturas de Software Arquitecturas de Software
Concerns
Concerns
Thinking time
Response time
Latency
Throughput
Scalability
Bursty
Vegetative
Predictability
Peak load and the knee
Tactics
Tactics
11
Arquitecturas de Software Arquitecturas de Software
Tactics
Tactics
Resource consumption
Computational efficiency
Computational overhead
Manage Event Rate
Control Frecuency of Sampling
Resource arbitration
Scheduling
Dispatching
Priority assignment:
fifo,
deadline of request,
semantic importance
Resource Management
Concurrency
Increase availability
Maintain multiple copies of computation and data
Tactics
Tactics
Disponibilidad
About faults and failiures
14
Arquitecturas de Software Arquitecturas de Software
Atributos de Calidad
Atributos de Calidad
Availability ( and resilence) :
Lahabilidaddelsistemadeestarcompletaoparcialmente
operacionalcuandoselorequiera(yparagestionar
efectivamentefallasquepuedanafectarsu
disponibilidad)
Concerns
Clases de servicios (QoS)
Tiempo fuera planeado
Tiempo de Recuperacin
Tasa de fallas
Recuperacin de desastres.
15
Arquitecturas de Software Arquitecturas de Software
La actividad de la oficina central se desarrolla
de lunes a viernes entre las 9.00 y las 18
hs, mientras que las tiendas estn abiertas
al pblico entre las 8.00 y las 22.00 hs y las
bvedas operan entre las 6.00 am y las
2.00 am del siguiente da. se espera que
la disponibilidad est relacionada con el
horario y necesidad funcional.
Ejemplo class of service: la disponibilidad est
relacionada con el horario y necesidad funcional de
las tienda para su correcta operacin.
16
Arquitecturas de Software Arquitecturas de Software
El mantenimiento planeado del sistema se
puede realizar fuera de los horarios de
operacin de las bvedas de las tiendas. El
plan de contingencia permite estar en
condiciones extraordinarias a lo sumo 2 das
laborales sin servicio de ningn tipo.
Ejemplo downtime: (planned) mantenimiento
planeado fuera de los horarios de operacin
Ejemplo downtime: (unplanned) plan de
contingencia permite estar en condiciones
extraordinarias a lo sumo 2 das laborales sin servicio
de ningn tipo
17
Arquitecturas de Software Arquitecturas de Software
Concerns
Concerns
Class of service
Downtime
Planned
Unplanned
Time to repair
Disaster recovery
Tactics
Tactics
19
Arquitecturas de Software Arquitecturas de Software
Tactics
Tactics
Fault detection
Ping / Echo
Heartbeat
Exception
Fault recovery
Recovery / Preparation / Repair
Active redundancy
Passive redundancy
Spare
Recovery reintroduction
Shadow
Synch
Rollback
Fault prevention
Removal from service
Process monitor
Transactions
Tactics
Tactics
Seguridad
Balancing paranoia and quality
22
Arquitecturas de Software Arquitecturas de Software
Atributos de Calidad
Atributos de Calidad
seguridad:
Lahabilidaddeunsistemaparacontrolar,monitoreary
auditarenformaconfiablequinpuederealizarqu
accionessobreelsistemaysusrecursos,ylahabilidad
paradetectaryrecobrardefallasenlossistemasde
seguridad.
Concerns
Polticas
Amenazas
Disponibilidad
Deteccin de ataques
Recuperacin de ataques
23
Arquitecturas de Software Arquitecturas de Software
Una vez confirmada una transaccin, el usuario
no puede negar su responsabilidad en la
accin, y cualquier cambio debe ser realizado
por instancia de auditora de la oficina de
control de ventas. Este requerimiento es ms
fuerte al momento de confirmar transacciones
con gran impacto en el flujo de fondos como
ser la confirmacin del depsito bancario que
sale al banco, y el arqueo con la conformidad
del nuevo responsable que asume el turno.
Ejemplo nonrepudation: el usuario no puede negar su
responsabilidad en la accin.
Ejemplo assurance: Este requerimiento es ms fuerte al
momento de confirmar transacciones con gran impacto en
el flujo de fondos
24
Arquitecturas de Software Arquitecturas de Software
Concerns
Concerns
Nonrepudation
Confidentiality
Integrity
Assurance
Availability (*)
Audit
Tactics
Tactics
26
Arquitecturas de Software Arquitecturas de Software
Tactics
Tactics
Aplicar reconocidas prcticas de seguridad
Otorgar el mnimo necesario de privilegios
Asegurar el punto ms dbil
No confiar en la oscuridad
Usar valores por omisin seguros
Fallar en forma segura
Asumir que las entidades externas no son seguras
Auditar eventos sensitivos
Autenticar los principals
Autorizar acceso
Asegurar confidencialidad de la informacin
Asegurar integridad de la informacin
27
DREAD: posible Dao,
Reproducibilidad, capacidad de ser
Explotado, usuarios Afectados y
capacidad de ser Descubierto
DREAD: posible Dao,
Reproducibilidad, capacidad de ser
Explotado, usuarios Afectados y
capacidad de ser Descubierto
Tactics
Tactics
Modificabilidad
About cost of change and its prediction
30
Arquitecturas de Software Arquitecturas de Software
Atributos de Calidad
Atributos de Calidad
modifiability:
Lahabilidaddelsistemaparaserflexiblefrenteacambios
inevitablesdurantesudesarrolloyluegodeldespliegue.
(enbalancecostodeconstruccindentrodeestos
trminosversuselcostodecambio)
Concerns
Probabilidad de cambio
Magnitud y dimensin de cambio
Costo del cambio
Complejidad del cambio
Conservacin del conocimiento de la solucin
Confiabilidad del cambio
31
Arquitecturas de Software Arquitecturas de Software
El modelo de negocio que da soporte al
registro de fondos se encontrar
implementado avanzado sobre el ciclo de
vida del software. Se debe poder reproducir
la experiencia de usuario en el uso de esta
interfaz de modo de asegurar el
requerimiento es implementable.
Qu debo poder implementar en un prototipo que
cumpla con relevar este requerimiento?
Qu relacin tiene esto con las decisiones de donde
sucede la computacin?
32
Arquitecturas de Software Arquitecturas de Software
Concerns
Concerns
Qu puede cambiar?
Artifact
Cundo es realizado el cambio?
Environment
Quin puede hacer un cambio?
Source
Tactics
Tactics
34
Arquitecturas de Software Arquitecturas de Software
Tactics
Tactics
Localizar modificaciones (mdulos afectados)
Generalizacin
Coherencia Semntica
Anticipar cambios
Limitar opciones
Prevenir efecto de propagacin de cambios
Ocultar informacin
Conservar interfaces
Restringir caminos posibles de comunicacin
Usar intermediarios
Establecer contratos
Posponer momento de binding
Runtime / Configuration / Component replacement
Tactics
Tactics
Usabilidad
About understanding the user and the nature of her interaction
37
Arquitecturas de Software Arquitecturas de Software
Atributos de Calidad
Atributos de Calidad
usability:
Lafacilidadconlacuallaspersonasinteractanconla
aplicacinenformaefectiva,ysobrecomoelsistema
proveesoportealusuarioenestesentido.
Concerns
Interfaz de usuario
Proceso de negocio
Calidad de la informacin
Alineamiento de capacidad de usuario con interfaz.
Crecimiento de productividad acorde a aprendizaje en
el uso.
38
Arquitecturas de Software Arquitecturas de Software
El sistema debe maximizar la informacin
provista al usuario tendiente a aumentar su
confianza en que no est cometiendo
errores, y poder cancelar operaciones que
an no han finalizado. Una vez terminada
una transaccin esta no podr ser reversada
si implica un cambio de custodia de valores.
Ejemplo increasing confidence: cuando hay diferencia
no se le informa sobre el monto pero si se le indica
que existe diferencia para que efecte un recuento.
Ejemplo minimizing the impact of errors: El usuario
debe poder cancelar la operacin o cambiar valores
que no tengan asociada la firma de la contraparte
39
Arquitecturas de Software Arquitecturas de Software
Concerns
Concerns
Funcionalidad orientadas al aprendizaje.
Eficiencia en el uso del sistema.
Minimizar el impacto de los errores.
Sistema que se adapta al usuario.
Incrementar confianza y satisfaccin.
Tactics
Tactics
41
Arquitecturas de Software Arquitecturas de Software
Tactics
Tactics
Ejecucin
Hacer buen uso de Human vs Computer
initiative
Modelo del usuario
Informacin sobre el conocimiento del usuario que sirve
para saber que tipo de respuesta ste espera.
Modelo de la tarea
Informacin sobre el contexto del proceso que sirve para
acotar las acciones posibles a las tiles al usuario.
Modelo del sistema
Informacin sobre la actividad que el sistema est
ejecutando y que es relevante para el usuario.
Tiempo de diseo
Separar interfaz del resto del sistema
Tactics
Tactics
Fin

También podría gustarte