Atributos de Calidad y Tcticas

Performance / Disponibilidad / Seguridad / Usabilidad / Modificabilidad

Atributos, concerns y tcticas

Una breve introduccin

Concerns y Escenarios

Arquitecturas de Software
3

Tcticas

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.
Arquitecturas de Software
4

Performance
About prediction of response time

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

Arquitecturas de Software
6

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.

Arquitecturas de Software
7

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.

Arquitecturas de Software
8

Concerns

Thinking time Response time Latency Throughput Scalability

Bursty Vegetative

Predictability Peak load and the knee

Arquitecturas de Software
9

Tactics

Tactics

Resource consumption

Resource arbitration
Scheduling Dispatching Priority assignment:
fifo, deadline of request, semantic importance

Computational efficiency Computational overhead Manage Event Rate Control Frecuency of Sampling

Resource Management

Concurrency Increase availability Maintain multiple copies of computation and data

Arquitecturas de Software
11

Tactics

Disponibilidad
About faults and failiures

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.

Arquitecturas de Software
14

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.
Arquitecturas de Software
15

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
Arquitecturas de Software
16

Concerns

Class of service Downtime

Planned Unplanned

Time to repair Disaster recovery

Arquitecturas de Software
17

Tactics

Tactics

Fault detection
Ping / Echo Heartbeat Exception

Fault recovery

Recovery / Preparation / Repair

Active redundancy Passive redundancy Spare Shadow Synch Rollback

Recovery reintroduction

Fault prevention

Removal from service Process monitor Transactions

Arquitecturas de Software
19

Tactics

Seguridad
Balancing paranoia and quality

Atributos de Calidad

seguridad: Lahabilidaddeunsistemaparacontrolar,monitoreary auditarenformaconfiablequinpuederealizarqu accionessobreelsistemaysusrecursos,ylahabilidad paradetectaryrecobrardefallasenlossistemasde seguridad.

Concerns Polticas Amenazas Disponibilidad Deteccin de ataques Recuperacin de ataques
Arquitecturas de Software
22

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
Arquitecturas de Software
23

Concerns

Nonrepudation Confidentiality Integrity Assurance Availability (*) Audit

Arquitecturas de Software
24

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
Arquitecturas de Software
26

DREAD: posible Dao, Reproducibilidad, capacidad de ser Explotado, usuarios Afectados y capacidad de ser Descubierto

27

Tactics

Modificabilidad
About cost of change and its prediction

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

Arquitecturas de Software
30

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?
Arquitecturas de Software
31

Concerns

Qu puede cambiar?
Artifact

Cundo es realizado el cambio?

Environment

Quin puede hacer un cambio?

Source

Arquitecturas de Software
32

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

Arquitecturas de Software
34

Tactics

Usabilidad
About understanding the user and the nature of her interaction

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.

Arquitecturas de Software
37

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
Arquitecturas de Software
38

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.

Arquitecturas de Software
39

Tactics

Tactics

Ejecucin

Hacer buen uso de Human vs Computer initiative

Modelo del usuario Modelo de la tarea
Informacin sobre el conocimiento del usuario que sirve para saber que tipo de respuesta ste espera. Informacin sobre el contexto del proceso que sirve para acotar las acciones posibles a las tiles al usuario. Informacin sobre la actividad que el sistema est ejecutando y que es relevante para el usuario.

Modelo del sistema

Tiempo de diseo

Separar interfaz del resto del sistema

Arquitecturas de Software
41

Tactics

Fin