Variabilidad
La variabilidad es una forma especial de modificabilidad. Se refiere a la habilidad de un sistema y sus artefactos tales como requerimientos, planes de test y especificación de configuración de soportar la producción de un conjunto de variantes que difieran entre si planeado de antemano.
Portabilidad
Es un caso especial de modificabilidad. La portabilidad se refiere a la facilidad con que un Software que fue construido para correr en una plataforma puede ser cambiada a correr en una plataforma diferente. La portabilidad se logran minimizando las dependencias con la plataforma en el programa, aislando las dependencias a ubicaciones bien definidas, y escribiendo el programa para que corra sobre una "máquina virtual" (como lo es Java Virtual Machine).
Desarrollo distribuido
La capacidad del desarrollo distribuido es la calidad del diseño para soportar el desarrollo de software distribuido. Muchos sistemas en estos días son desarrollados por equipos distribuidos globalmente. Uno de los problemas que debe ser superado con equipos distribuidos es coordinar sus actividades.
Escalabilidad
Dos tipos de escalabilidad son escalabilidad horizontal y escalabilidad vertical. La escalabilidad horizontal (scaling out) s refiere a la agregación de más recursos a unidades lógicas, como ser agregar otro server a un cluster de servidores. La escalabilidad vertical (scaling up) se refiere a la agregación de más recursos a una unidad física, como sería agregar más memoria a una computadora. En ambientes Cloud la escalabilidad horizontal es llamada elasticidad. Elasticidad es la propiedad que permite a los clientes agregar o remover maquinas virtuales a un pool de recursos.
Capacidad de despliegue
Capacidad de despliegue (deployability) se refiere a como un ejecutable llegar a la plataforma del host y como esta es subsecuentemente invocada. Algunos de los inconvenientes involucgrados en el despliege de software son: Como hacer para llegar al host (push, donde las actualizaciones son enviadas a los usuarios sin ser pedidos, o pull, donde los usuarios deben explicitamente pedir las actualizaciones)? Como este es integrado al sistema existente? Puede esto realizarse cuando el sistema existente está en ejecución?
Movilidad
Movilidad aborda el problema de movimiento y prestaciones de una plataforma (ej, tamaño, tipo de pantalla, tipo de dispositivos de entrada, disponibilidad, volumen de ancho de banda, y vida de la batería). Los problemas en movilidad incluyen administración de la batería, reconexión después de un periodo de desconexión, y el número de diferentes interfaces de usuario necesarias para soportar múltiples plataformas.
Capacidad de Monitoreo
(Monitorability) trata de la habilidad del equipo de operaciones para monitorear el sistema mientras se está ejecutando. Cosas como longitudes de cola, tiempo promedio de procesamiento de transacciones, y la salud de varios componentes deberían ser visibles al equipo de operaciones de manera que puedan tomarse las acciones correctivas en caso de problemas potenciales.
Seguridad
La seguridad del software es acerca de la habilidad del software para evitar entrar en estados que causen o provoquen daños, lesiones, o perdida de la vida a los actores en el ambiente del software, y a recuperar o limitar el daño cuando lo hace entrar en un mal estado. Otro manera de decir esto es que la seguridad tiene que ver con la prevención de y recuperación de fallas peligrosas.
La seguridad no es lo mismo que confiabilidad. Un sistema puede ser confiable (consistente con sus especificaciones) pero todavía inseguro (por ejemplo, cuando la especificación ignora condiciones que dan lugar a una acción insegura)
#sysadmin, #devops, #python y #erlang
Mostrando las entradas con la etiqueta atributos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta atributos. Mostrar todas las entradas
miércoles, 8 de enero de 2014
martes, 1 de octubre de 2013
Disponibilidad - Capitulo 5
Resumen del Libro
La disponibilidad refiere a la habilidad del sistema de estar disponible para el uso, especialmente luego de que ocurra un error. El error debe ser reconocido (o prevenido) y entonces el sistema debe responder de algún modo. La respuesta deseada dependerá de la criticidad de la aplicación y el tipo de error, que puede ir desde 'ignorarlo' a 'seguir adelante como si no hubiera pasado nada'-
Las tácticas para la disponibilidad son categorizadas dentro de los siguientes:
Detectar errores, recuperarse de errores y prevenirlos. Las tácticas de detección dependen esencialmente, de la detección de signos vitales de varios componentes. Las tácticas de recuperación son alguna combinación de re intentos de una operación o el mantenimiento de datos y procesamiento redundantes. Las tácticas de prevención dependerán tanto de remover elementos del servicio o utilizar mecanismos para limitar el alcance del error.
Todas las tácticas de disponibilidad involucran al modelo de coordinación por que este debe estar al tanto de las fallas que ocurren para generar una respuesta apropiada.
Este es el resumen que el libro ofrece para el Capitulo 5 pero voy a tratar de agregar algo más ya que hay temas que son bastante amplios y el libro tiene un detalle interesante para este cápitulo.
SLA (Service Level Agreement): La disponibilidad prevista por un sistema de computación o servicio de Hosting es frecuentemente expresada como un "Acuerdo de Nivel de Servicio" (Service Level Agreement). Este SLA especifica el nivel de disponibilidad que es garantizado y, usualmente, las penalidades que el sistema de computación o servicio de hosting sufrirán si el SLA es violado.
Como se lee en el capitulo anterior [0] los atributos de calidad son analizados en un Escenario que define varias cuestiones con respecto al contexto. Aquí lo haremos en base a la Disponibilidad.
Origen del estimulo: Interno o externo: personas, hardware, software, infraestructura física, ambiente, etc.
Estimulo: Error, omission, error grave, sincronización incorrecta, respuesta incorrecta.
Artefacto: Procesadores, canales de comunicación, almacenamiento persistente, procesos.
Ambiente: Operación normal, inicio, apagado, modo de reparación, operación degradada, operación en sobrecarga.
Respuesta: Prevenir que la falta se convierta en una falla.
Detectar la falla:
[0] http://gonzamartinez.blogspot.com.ar/2013/09/entendiendo-los-atributos-de-calidad_23.html
La disponibilidad refiere a la habilidad del sistema de estar disponible para el uso, especialmente luego de que ocurra un error. El error debe ser reconocido (o prevenido) y entonces el sistema debe responder de algún modo. La respuesta deseada dependerá de la criticidad de la aplicación y el tipo de error, que puede ir desde 'ignorarlo' a 'seguir adelante como si no hubiera pasado nada'-
Las tácticas para la disponibilidad son categorizadas dentro de los siguientes:
Detectar errores, recuperarse de errores y prevenirlos. Las tácticas de detección dependen esencialmente, de la detección de signos vitales de varios componentes. Las tácticas de recuperación son alguna combinación de re intentos de una operación o el mantenimiento de datos y procesamiento redundantes. Las tácticas de prevención dependerán tanto de remover elementos del servicio o utilizar mecanismos para limitar el alcance del error.
Todas las tácticas de disponibilidad involucran al modelo de coordinación por que este debe estar al tanto de las fallas que ocurren para generar una respuesta apropiada.
Este es el resumen que el libro ofrece para el Capitulo 5 pero voy a tratar de agregar algo más ya que hay temas que son bastante amplios y el libro tiene un detalle interesante para este cápitulo.
SLA (Service Level Agreement): La disponibilidad prevista por un sistema de computación o servicio de Hosting es frecuentemente expresada como un "Acuerdo de Nivel de Servicio" (Service Level Agreement). Este SLA especifica el nivel de disponibilidad que es garantizado y, usualmente, las penalidades que el sistema de computación o servicio de hosting sufrirán si el SLA es violado.
Como se lee en el capitulo anterior [0] los atributos de calidad son analizados en un Escenario que define varias cuestiones con respecto al contexto. Aquí lo haremos en base a la Disponibilidad.
Origen del estimulo: Interno o externo: personas, hardware, software, infraestructura física, ambiente, etc.
Estimulo: Error, omission, error grave, sincronización incorrecta, respuesta incorrecta.
Artefacto: Procesadores, canales de comunicación, almacenamiento persistente, procesos.
Ambiente: Operación normal, inicio, apagado, modo de reparación, operación degradada, operación en sobrecarga.
Respuesta: Prevenir que la falta se convierta en una falla.
Detectar la falla:
- Registrar la falla.
- Notificar a las entidades apropiadas (personas o sistemas)
- Deshabilitar el origen de los eventos que causan la falla.
- Estar temporalmente no disponible mientras se hace la reparación.
- Resolver o enmascarar la falta/falla o contener los daños que esta causa.
- Operar en modo degradado mientras se hace la reparación.
Medida de respuesta: Tiempo o intervalo de tiempo cuando el sistema debe estar disponible.
Porcentaje de disponibilidad (como por ejemplo el SLA de muchos Hostings que es del 99,999%)
Tiempo para detectar la falta.
Tiempo para reparar la falta.
Tiempo o intervalo de tiempo en que el sistema puede estar en modo degradado.
Proporción (99%) o ritmo (arriba de 100 por segundo) de una cierta clase de falla que el sistema previene o maneja sin salir de servicio.
Para seguir profundizando en un Post Posterior :D. Siempre quise decir eso. Se analizarán las tacticas de disponibilidad que son varias y que en el libro están muy bien detalladas. Estás como vimos al principio van a estar categorizadas en Detección, recuperación y prevención de una falla.
[0] http://gonzamartinez.blogspot.com.ar/2013/09/entendiendo-los-atributos-de-calidad_23.html
lunes, 23 de septiembre de 2013
Entendiendo los Atributos de Calidad Capitulo 4 (2)
En el Post anterior de Atributos de calidad [0] se hablaba sobre el escenario de atributos de calidad y se hablo sobre sus partes en esta sección vamos a detallar cada uno de estos.
Origen del estimulo: Esta es alguna entidad (un humano, un sistema, o cualquier otro actuador) que generó el estimulo.
Estimulo: El estimulo es una condición que requiere una respuesta cuando esta llega al sistema.
Ambiente: El estimulo occurre bajo ciertas condiciones. El sistema puede ser in una condición de sobrecarga o en condiciones normales, o algún otro estado relevante. Para algunos sistemas, la operación "normal" puede referirse de uno a varios modos. Para este tipos de sistemas, el ambiente debería especificar en que modo el sistema esta ejecutándose.
Artefacto: Algún artefacto es estimulado. Este puede ser una colección de sistemas, todo el sistema o alguna pieza o piezas de este.
Respuesta: La respuesta es la actividad realizada como el resultado de el arribo de el estimulo.
Medida de respuesta: Cuando la decisiones de diseño respuesta ocurre, esta deberia ser medible en cierto modo para que el requerimiento pueda ser probado.
Según el libro "Software Architecture in Practice" una táctica arquitectural es una decisión de diseño que afecta a la respuesta de un atributo de calidad. Estas son dividas en siete categorias que tratare de resumirles a continuación.
Asignación de responsabilidades: Las decisiones que participan de la asignación de responsabilidades incluyen las siguientes:
Los programas trabajan por tener elementos que interactuan entre sí a través de mecanismos diseñados. Estos mecanismos son colectivamente referidos como modelo de coordinación. Estos incluyen:
[0] http://gonzamartinez.blogspot.com/2013/09/entendiendo-los-atributos-de-calidad.html
Origen del estimulo: Esta es alguna entidad (un humano, un sistema, o cualquier otro actuador) que generó el estimulo.
Estimulo: El estimulo es una condición que requiere una respuesta cuando esta llega al sistema.
Ambiente: El estimulo occurre bajo ciertas condiciones. El sistema puede ser in una condición de sobrecarga o en condiciones normales, o algún otro estado relevante. Para algunos sistemas, la operación "normal" puede referirse de uno a varios modos. Para este tipos de sistemas, el ambiente debería especificar en que modo el sistema esta ejecutándose.
Artefacto: Algún artefacto es estimulado. Este puede ser una colección de sistemas, todo el sistema o alguna pieza o piezas de este.
Respuesta: La respuesta es la actividad realizada como el resultado de el arribo de el estimulo.
Medida de respuesta: Cuando la decisiones de diseño respuesta ocurre, esta deberia ser medible en cierto modo para que el requerimiento pueda ser probado.
Según el libro "Software Architecture in Practice" una táctica arquitectural es una decisión de diseño que afecta a la respuesta de un atributo de calidad. Estas son dividas en siete categorias que tratare de resumirles a continuación.
Asignación de responsabilidades: Las decisiones que participan de la asignación de responsabilidades incluyen las siguientes:
- Identificar las responsabilidades importantes, incluyendo las funciones básicas del sistema, infraestructura arquitectonica, y la satisfacción de los atributos de calidad.
- Determinar como estas responsabilidades son asignadas a non-runtime y elementos runtime. (es decir, modulos, componentes y conectores).
Las estrategias para hacer estas decisiones incluyen descomposición funcional, modelado de objetos del mundo real, agrupación basada en los modos principales de operación del sistema o agrupación basada en requerimientos de calidad similares.
Modelo de Coordinación:
Los programas trabajan por tener elementos que interactuan entre sí a través de mecanismos diseñados. Estos mecanismos son colectivamente referidos como modelo de coordinación. Estos incluyen:
- Identificar los elementos del sistema que deben coordinarse, o que tienen prohibido coordinarse.
- Determinar las propiedades de la coordinación, tales como la puntualidad, vigencia, completitud, exactitud, y consistencia.
- Seleccionar los mecanismos de comunicación (entre sistemas, entre nuestro sistema y entidades externas, entre elementos de nuestro sistema) que realizan estas propiedades.
En el próximo post tratare de resumir las otras 5 propiedades que todavia faltan. que son Modelo de Datos, Administración de Recursos, Mapeo entre elementos arquitectonicos, decisiones de fusión de tiempo, elección de tecnología.
[0] http://gonzamartinez.blogspot.com/2013/09/entendiendo-los-atributos-de-calidad.html
Suscribirse a:
Entradas (Atom)