Ir al contenido principal

Atributos de Calidad

Son las expectativas de usuario, en general impl铆citas, de cuan bien funcionar谩 un producto. Los atributos tienen identidad en si mismos y son las cualidades de la que todos hablamos, cuando un sistema es bueno o malo en alg煤n aspecto.

"Los atributos de calidad son las expectativas de usuario, en general impl铆citas, de cu谩n bien funcionar谩 un producto." Software Requirements: 3rd Edition (Wiegers, Betty, 2013)

Dominio: Arquitectura de Software.

Idoneidad Funcional 

Tiene que ver con la conexi贸n del usuario (tareas u objetivos a resolver con el sistema) y como est谩n implementadas funcionalmente en dicho sistema. Se puede dividir en 3 partes:

  • Completitud funcional: cuan completa esta la implementaci贸n con respecto a lo que se espera del sistema. Requerimientos Funcionales vs Funcionalidades implementadas.
  • Exactitud funcional: cuan preciso es el sistema para implementar lo requerido. Resultados Esperados vs Resultados Obtenidos.
  • Pertinencia funcional: cuan alineado esta lo que se implemento con lo requerido. Objetivos Cumplidos vs Objetivos Esperados.

Eficiencia de ejecuci贸n

Trata de que tan eficiente es el sistema a la hora de responder y del propio sistema, como aprovecha o desaprovecha los recursos.

Se divide en 3 partes cada una con atributos que deben ser comparados entre si:

  • Tiempo de comportamiento: Tiempo transcurrido entre: Pedido vs Respuesta y Tiempo esperado vs Tiempo m谩ximo tolerado.
  • Uso de recursos: Consumo de recursos vs Consumo esperado.
  • Capacidad: L铆mite de tolerancia detectado vs L铆mite de tolerancia esperado

Compatibilidad

Grado en el cual un producto, sistema o componente puede intercambiar informaci贸n con otros productos, sistemas o componentes, y/o realizar las funciones requeridas, mientras comparte el mismo entorno de hardware o software.

Esta caracter铆stica se compone de las siguientes subcaracter铆sticas:

  • Interoperabilidad: Grado en el cual dos o m谩s sistemas, productos o componentes pueden intercambiar informaci贸n y usar la informaci贸n que se ha intercambiado.
  • Coexistencia: Grado en el cual un producto puede realizar sus funciones requeridas de manera eficiente mientras comparte un entorno y recursos comunes con otros productos, sin impacto perjudicial en ning煤n otro producto.

Usabilidad

Grado en el cual un producto o sistema puede ser utilizado por usuarios espec铆ficos para alcanzar objetivos espec铆ficos con efectividad, eficiencia y satisfacci贸n en un contexto de uso espec铆fico. Esta caracter铆stica se compone de las siguientes subcaracter铆sticas:

  • Reconocimiento de idoneidad. Grado en el cual los usuarios pueden reconocer si un producto o sistema es apropiado para sus necesidades. Ej: Appro. recog: Wordpress usado para cualquier cosa que no sea blog.
  • Curva de aprendizaje. Grado en que un producto o sistema puede ser utilizado por usuarios espec铆ficos para lograr objetivos espec铆ficos de aprender a utilizar el producto o sistema con efectividad, eficiencia, ausencia de riesgo y satisfacci贸n en un contexto de uso espec铆fico. Ej: Lenguaje de gestos en aplicaciones m贸viles.
  • Operabilidad. Grado en el cual un producto o sistema tiene atributos que hacen que sea f谩cil de operar y controlar. Ej: Formularios largos o de m煤ltiples pasos. Sistemas gubernamentales.
  • Protecci贸n de errores. de usuario Grado en el que un sistema protege a los usuarios contra errores. EJ: Sistemas de pago, incertidumbre en el estado del pago.
  • Est茅tica de la interfaz de usuario. Grado en el cual una interfaz de usuario permite una interacci贸n agradable y satisfactoria para el usuario. Ej: UI vs UX.
  • Accesibilidad. Grado al cual un producto o sistema puede ser utilizado por personas con la m谩s amplia gama de caracter铆sticas y capacidades para alcanzar un objetivo espec铆fico en un contexto de uso espec铆fico. Ej: im谩genes con texto, sin alt. Contenido redundante o mal marku.

Confiabilidad

Atributos que tienen que tienen que ver con el uso normal del sistema a trav茅s del tiempo:
  • Madurez. El grado en que un sistema, producto o componente satisface necesidades de confiabilidad bajo operaci贸n normal. Ej: Sistemas de compras. Sistemas bancarios.
  • Disponibilidad. Grado en el cual un sistema, producto o componente es operacional y accesible cuando se requiere su uso. Ej: SLAs, contratos de servicio. Sistemas con eventos de carga pico puntuales.
  • Tolerancia a fallos. Grado en el que un sistema, producto o componente funciona seg煤n lo previsto a pesar de la presencia de fallas de hardware o software. Ej Aplicaciones m贸viles.
  • Capacidad de recuperaci贸n. Grado en el que, en caso de interrupci贸n o falla, un producto o sistema puede recuperar los datos directamente afectados y restablecer el estado deseado del sistema. Ej Sistemas distribuidos, configuraciones auto-escalables en la nube. Puede estar conectado a la mantenibilidad.

Seguridad

Es grado en que un producto o sistema protege la informaci贸n y los datos para que las personas u otros productos o sistemas tengan el grado de acceso a los datos apropiado para sus tipos y niveles de autorizaci贸n. Esta caracter铆stica se compone de las siguientes subcaracter铆sticas:

  • Confidencialidad. Grado en el cual un producto o sistema asegura que los datos solo sean accesibles para aquellos autorizados a tener acceso. Ej: Redes sociales.
  • Integridad. Grado en el que un sistema, producto o componente impide el acceso no autorizado o la modificaci贸n de programas o datos de computadora. Ej: Sistemas bancarios.
  • Comprobaci贸n de hecho. Grado en que se puede demostrar que las acciones o eventos tuvieron lugar, para que los eventos o acciones no puedan ser repudiados m谩s tarde. Ej: Firmas digitales. Logs de auditor铆a.
  • Traza de responsabilidad. Grado en el que las acciones de una entidad se pueden rastrear de manera 煤nica a la entidad. Ej: Logs de auditor铆a.
  • Autenticidad. Grado en el cual se puede probar que la identidad de un sujeto o recurso es la reclamada. Ej: Autenticaci贸n de 2 factores. Correo electr贸nico, n煤mero de tel茅fono. Datos biom茅tricos.

Mantenibilidad

Esta caracter铆stica representa el grado de efectividad y eficiencia con la que un producto o sistema puede ser modificado para mejorarlo, corregirlo o adaptarlo a los cambios en el entorno y en los requisitos. Esta caracter铆stica se compone de las siguientes subcaracter铆sticas:

  • Modularidad. Grado en el cual un sistema o programa de computadora se compone de componentes discretos tales que un cambio en un componente tiene un impacto m铆nimo en otros componentes. Ej: Patrones de arquitectura. Sistemas distribu铆dos.
  • Reusabilidad. Grado en el cual un activo puede ser utilizado en m谩s de un sistema, o en la construcci贸n de otros activos. Ej: C贸digo de c贸digo abierto.
  • Analizabilidad. Grado de efectividad y eficiencia con el cual es posible evaluar el impacto en un producto o sistema de un cambio intencional a una o m谩s de sus partes, o diagnosticar un producto por deficiencias o causas de fallas, o identificar partes a ser modificadas . Ej: Conexi贸n entre c贸digo y requerimiento.
  • Modificabilidad. Grado en que un producto o sistema puede ser modificado de manera efectiva y eficiente sin introducir defectos o degradar la calidad del producto existente. Ej: Cobertura de c贸digo en tests.
  • Testabilidad. Grado de eficacia y eficiencia con el que se pueden establecer los criterios de prueba para un sistema, producto o componente y se pueden realizar pruebas para determinar si se han cumplido esos criterios. Ej: Funciones puras: ayuda efectos secundarios. Principio de responsabilidad 煤nica. Buenas pr谩cticas de dise帽o.

Portabilidad

Grado de eficacia y eficiencia con el que un sistema, producto o componente puede transferirse de un hardware, software u otro entorno operacional o de uso a otro. Esta caracter铆stica se compone de las siguientes subcaracter铆sticas:

  • Adaptabilidad. Grado en el cual un producto o sistema puede ser adaptado efectiva y eficientemente para hardware, software u otros entornos operacionales o de uso diferentes o en evoluci贸n. Ej: Arquitecturas espec铆ficas de dominio. Abstracci贸n y separaci贸n.
  • Instalabilidad. Grado de eficacia y eficiencia con el que un producto o sistema puede instalarse y / o desinstalarse con 茅xito en un entorno espec铆fico. Ej: Tiendas de aplicaciones.
  • Reemplazabilidad. Grado en el cual un producto puede reemplazar otro producto de software especificado para el mismo prop贸sito en el mismo entorno. Ej: Sistemas distribuidos, microservicios.

Tensiones entre atributos

En s铆ntesis, es imposible dar una soluci贸n que aproveche el 100% de las capacidades de todos los atributos de calidad. Cuando se prioriza un atributo de calidad pierde capacidades de otros. Est谩 dentro las labores del arquitecto definir qu茅 atributo se le dar谩 prioridad y asumir cuales otros van a perder su capacidad. Ese ejercicio es conocido como Trade Off.



Notas del Curso Profesional de Arquitectura de Software.

Comentarios

Entradas populares de este blog

Patrones de Arquitectura

Son decisiones de dise帽o importantes ya tomadas para generar un esquema, estructura o tipo de comunicaci贸n entre componentes. Dominio:  Arquitectura de Software. Patrones monol铆ticos vs distribuidos Monol铆ticos : En este tipo de patrones, se entiende que existe una comunicaci贸n directa entre las partes del sistema, pero al distribuir dicho sistema este funciona como un ente 煤nico, esto dificulta la manutenci贸n del mismo pues no se pueden alterar partes especificas sin afectar al sistema en su totalidad, sin embargo, se puede desarrollar de manera m谩s r谩pida. Distribuidos : En este caso, el patr贸n distribuido es aquel que despliega el sistema en forma seccionada, cada uno de los subsistemas funcionan como entes monol铆ticos de por si, esto facilita la manutenci贸n o la alteraci贸n de estos subsistemas sin da帽ar el sistema en su totalidad, sin embargo, se debe tener cuidado de generar inconvenientes de comunicaci贸n entre los subsistemas. Gran Bola de Lodo : Es un patr贸n que surge del descui

Dise帽o de una Arquitectura

¡Maravilloso este punto, tantas opciones para elegir puede hacer que tomes una decisi贸n no acertada… pero si basamos nuestra decisi贸n en la experiencia ajena (exitosamente probada), seguro que llegamos a puerto seguro! Dominio:  Arquitectura de Software. Primer paso para crear una arquitectura. Pararse en hombros de gigantes Aprovechar el conocimiento existente para nuestra soluci贸n. Productos “de la estanter铆a”. Productos ya echos que resuelvan parte de nuestros problemas. Frameworks y librer铆as. Ayuda a empezar/proponer desde una arquitectura m谩s especifica. Arquitecturas especificas del dominio. Decisiones de dise帽o ya tomadas para ciertos dominios del problema. Patrones de arquitectura. Empezar desde un punto mas solido y restringir nuestro dise帽o a las partes importantes que quedan por resolver. Herramientas y partes de un dise帽o: Tipos de conectores La arquitectura est谩 separada en dos partes fundamentales: Componentes : Son partes de nuestro sistema que cumplen una funci贸n espec