Calidad de Software

Análisis y Diseño de Sistemas II

 Calidad
Es la aptitud de un producto o servicio para satisfacer las necesidades del
usuario.

Es la cualidad de todos los productos, no solamente de equipos sino también

de programas.

En el desarrollo de software, la calidad de diseño acompaña a la calidad de los

requisitos, especificaciones y diseño del sistema. La calidad de concordancia
es un aspecto centrado principalmente en la implementación; Si la
implementación sigue al diseño, y el sistema resultante cumple con los
objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
 ¿Qué es Calidad de Software?
Proceso eficaz de software que se aplica de manera que crea un producto útil
que proporciona valor medible a quienes lo producen y a quienes lo utilizan

David Garvin (1984) plantea desde un punto de vista:

● Trascendental: se reconoce pero es difícil de definir
● Usuario: cumple los requerimiento y funcionalidad
● Fabricante: cumple las especificaciones originales
● Producto: implementación de funciones y características
● Valor: lo que el cliente está dispuesto a pagar

Según ISO 9000:2000 : La calidad es el “grado en el que un conjunto de

características inherentes cumple con los requisitos”.
 ¿Quién la consigue?
Todos los involucrados en el proceso de software:
● Gerentes
● Ingenieros
● arquitectos de software
● QA
● Test developer
● Implementadores

¿La Calidad es un medio o un fin?

La calidad no debe ser el fin, sino un medio para obtener una mejora en la
satisfacción para un bien o producto.
 ¿Por qué es importante?
Reduce costos por repetición y mejora la entrada al mercado.

Un software de calidad, SATISFACE MEJOR las necesidades de los clientes y

es un medio de obtener MÁS GANANCIAS.

El problema del software en el mundo

● El 25% de todos los proyectos de software se cancelan.
● Las compañías liberan los productos con un 15% de defectos.
● Las compañías gastan entre un 30 y 44% de su tiempo y dinero re
trabajando sobre el código ya escrito.
● Las compañías cumplen sólo en un 50 % de las veces.
 ¿Por qué es importante?
La importancia radica principalmente en entregar productos de calidad
esperada, en donde se previenen riesgos a futuro.

Mientras más tarde se detecten los defectos o errores, mayores pueden ser las
consecuencias.

El objetivo, es que logre soportar todos los requerimientos, sea amigable,

seguro, útil, usable, estable y satisfaga las necesidades y requerimientos del
usuario sin que presente fallos o errores.
 ¿Por qué es importante?
Dado que las pruebas de calidad de software revisan, supervisan y examinan
la forma en que se desenvuelve el producto, es posible contar con un informe
final en el que se establece si el software cumple o no con lo que espera el
usuario, según el motivo por el cual fue hecho.

A la vez que se comprueba la exactitud y confiabilidad de los procesos

apoyados en cada una de las pruebas realizadas: funcionales y no funcionales.
Fallos Informáticos
Las causas de los fallos informáticos pueden ser ticos pueden ser muy diversas:

● Especificaciones incorrectas o incompletas

● Análisis equivocados

● Diseños con fallos

● Programación con errores

● Validación poco precisa

● No contar con gestión de pruebas

● Deficiencia en la gestión de datos de prueba

● Subestimar la planificación y la complejidad del software

● No automatizar las pruebas

 Normas ISO
ISO (International Standarization Organization) es la organización que se encarga de
la creación de normas de fabricación, comercio y comunicación que tienen un
alcance internacional. La obtención de una certificación ISO en alguna de sus
normas, garantiza que la empresa o profesional que la posea sigue las normas o
estándares para asegurar la calidad, seguridad y eficiencia de sus servicios o
productos.

Los principales beneficios que proporciona el cumplimiento de las normas ISO son:
● Mejoran los procesos y aumentan la productividad.
● Mejoran el reconocimiento de la marca y la reputación de la empresa.
● Asegura las mejores prácticas a nivel internacional.
● Dan acceso a licitaciones públicas que exigen cumplir normativas ISO.
● Facilita la colaboración y el comercio entre empresas certificadas.
Normativa ISO 9000
La certificación del software es consecuencia del proceso de aseguramiento de la calidad, pero nunca es
el objetivo final. La calidad de software no se certifica, lo que se certifica, son los procedimientos para
construir un software de calidad. Los procedimientos deben ser correctos y estar en función de la
normalización (ISO 9000, CMMI, Moprosoft, etc.).

La Normativa ISO 9000 Pone a disposición de un auditor o certificador los procesos internos, de forma
que este indique si cumple o no la normativa al 100%, se audita el sistema. Si los resultados son positivos,
se emite la certificación, y cada cierto tiempo se tiene que renovar. La certificación es costosa, como
consecuencia de los costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses).
Finalmente se certifican la empresa, y la metodología para el desarrollo de la aplicación.
 Modelos de Calidad
Intentan cuantificar la calidad del software
Se descompone la calidad en niveles estructurados
Los distintos modelos se diferencian por:
● la relación entre los niveles
● la cantidad de niveles
● los conceptos de cada nivel

Tres tipos de modelos importantes:

Calidad del producto: propiedades del producto según usuario y según desarrollador (Valor técnico)
Calidad del proceso: actividades que influyen en calidad del producto (Valor técnico)
Calidad en uso: relación del producto con el ambiente donde se le emplea (Valor comercial)
Modelos de Calidad
Los modelos de calidad son aquellos documentos que integran la mayor
parte de las mejores prácticas, proponen temas de administración en los
que cada organización debe hacer énfasis, integran diferentes prácticas
dirigidas a los procesos clave y permiten medir los avances en calidad.

Los modelos de calidad de software generalmente están estructurados

como se muestra en la Figura, donde se pueden tener diversos factores
de calidad que a su vez se componen de criterios que son evaluados por
métricas, con el propósito de abordar la evaluación desde lo general a lo
particular, y permitir la reducción de la subjetividad en la asignación de un
valor, ya sea cuantitativo o cualitativo.
Calidad en uso
Es importante resaltar que aunque en diferentes escenarios se utilizan los
términos usabilidad y calidad en uso, con el mismo propósito y de forma
intercambiable tienen significados distintos, principalmente porque el
concepto de calidad en uso es más amplio y abarca más elementos que la
usabilidad, y esta última es una de las características de calidad de un
producto software.

La calidad en uso se define como el "conjunto de atributos relacionados

con la aceptación por parte del usuario final y seguridad", y está basada en
la eficacia, productividad, seguridad y satisfacción, según ISO/IEC 9126.
Normativa ISO/IEC 9126
ISO 9126 era un estándar internacional para la evaluación de la calidad del software. Fue reemplazado en 2005 por el
conjunto de normas SQuaRE, ISO 25000:2014, la cual desarrolla los mismos conceptos.

El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1, clasifica la calidad del software en un
conjunto estructurado de características y subcaracterísticas. Cada subcaracterística está dividida en atributos. Un atributo
es una entidad la cual puede ser verificada o medida en el producto software. Los atributos no están definidos en el
estándar, ya que varían entre diferentes productos software. Las características se organizan de la siguiente manera:

Usabilidad - Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la valoración individual de tal
uso, por un establecido o implicado conjunto de usuarios.

● Aprendizaje
● Comprensión
● Operatividad
● Atractividad
Modelos a nivel de proceso
La calidad de un sistema software debe ser programada desde el inicio del proyecto, y posteriormente en cada
etapa del proceso de desarrollo se debe llevar a cabo el control y seguimiento de los aspectos de calidad, para
minimizar los riesgos y ofrecer soporte continuo, se garantiza así un óptimo nivel de cumplimiento de los
factores de calidad, teniendo en cuenta que si en alguna de las etapas se deja de lado la verificación de los
factores y criterios es posible que se presente deficiencia en alguno de éstos y disminuirá el nivel de calidad no
solo del proceso, sino también del producto en desarrollo.

Se presenta la línea de tiempo de algunos modelos a nivel de proceso.

Modelos a nivel de proceso
ITIL: cinco elementos fundamentales: la perspectiva del negocio, entrega del servicio, soporte del servicio, manejo de la
infraestructura y manejo de aplicaciones.
ISO/IEC 15504: seis niveles de madurez: Nivel 0- Organización inmadura, Nivel 1- Organización básica, Nivel 2-
Organización gestionada, Nivel 3- Organización establecida, Nivel 4- Organización predecible y Nivel 5- Organización
optimizando.
Bootstrap: seis actividades básicas: Examinar la necesidad, Iniciar proceso de mejora, preparación y dirección de la
evaluación, análisis de resultados, implantación y finalización de mejoras.
Dromey: propone tres modelos distintos para cada etapa de construcción del producto: modelo de requerimientos,
modelo de diseño y modelo de calidad de la implementación.
Personal Software Process (PSP): Este modelo está enfocado al desarrollo profesional del ingeniero, fomentando una
adecuada administración de calidad de los proyectos de desarrollo, reducción de defectos del producto, estimación y
planeación del trabajo.
Team Software Process (TSP): TSP es la fase posterior de PSP, está diseñado para el trabajo de equipos de desarrollo
de software autodirigidos, que se orienta al desarrollo de productos con el mínimo de defectos en tiempo y costos
estimados.
Modelos a nivel de proceso
IEEE / EIA 12207: Este estándar establece un marco de trabajo común para el ciclo de vida del desarrollo de software, a
partir del planteamiento de procesos, actividades y tareas que pueden ser aplicadas durante la adquisición, suministro,
desarrollo, operación, mantenimiento y/o despliegue de un producto software (ISO/IEC, 2008)
Cobit 4.0: siete criterios de información que son definidos como requerimientos de control del negocio: efectividad,
eficiencia, confidencialidad, integridad, disponibilidad, cumplimiento y confiabilidad.
ISO 90003: Conjunto de estándares utilizados para el desarrollo, suministro y soporte del software, cuyo propósito es
ofrecer una guía de aplicación de la norma 9001 que pretende ser utilizada para demostrar o soportar que la entidad está
en capacidad de desarrollar software con criterios de calidad. (ISO, 1998).
CMMI (Capability Maturity Model Integration): el modelo escalonado está dirigido al software y permite clasificar las
organizaciones en cinco tipos de nivel establecidos: Inicial, gestionado, definido, gestionado cuantitativamente y en
optimización; y por su parte el modelo continuo se enfoca al análisis de la capacidad de cada proceso inmerso en las
áreas de la ingeniería de sistemas y lo clasifica en uno de los siguientes seis niveles: Incompleto (0), ejecutado (1),
gestionado (2), definido (3), cuantitativamente gestionado (4) y en optimización (5).
ISO/IEC 20000: Se subdivide en dos partes: "Especificaciones", publicada como ISO 200001:2005, y "Código de buenas
prácticas" publicada como ISO 20000-2:2005.
Modelos a nivel de producto
La principal finalidad del modelo de calidad de producto es especificar y evaluar el cumplimiento de criterios del
producto, para lo cual se aplican medidas internas y/o medidas externas. Por esta razón, algunas normas y
estándares han definido la calidad a nivel de producto en tres tipos: interna, externa y en uso. Este enfoque está
orientado a verificar el cumplimiento de las características que permitan alcanzar la satisfacción del cliente en
cuanto a los requisitos definidos en las etapas iniciales del proceso de desarrollo.

Se presenta la línea de tiempo de algunos modelos de evaluación a nivel de producto.

Modelos a nivel de producto
McCall: Uno de los modelos pioneros en la evaluación de la calidad de software, tiene tres etapas definidas: factores,
criterios y métricas. Los once criterios base, son: Exactitud, confiabilidad, eficiencia, integridad, usabilidad, mantenibilidad,
testeabilidad, flexibilidad, portabilidad, reusabilidad e interoperabilidad (Khosravi, 2004).

GQM o Goal Question Metric: Se enfoca a proporcionar una forma que permita definir métricas para medir el avance
como los resultados de algún proyecto.

Boehm: cuatro sectores: planeación, análisis de riesgo, ingeniería y evaluación.

FURPS: criterios que evalúa: Funcionalidad, usabilidad, confiabilidad, desempeño y soportabilidad.

GILB: Modelo de calidad que orienta la evaluación de software a partir de los atributos: Capacidad de trabajo,
adaptabilidad, disponibilidad y utilizabilidad.

ISO 9126: Estándar basado en el modelo de McCall, dirigido a desarrolladores, aseguradores de calidad, evaluadores,
analistas y cualquier otro involucrado en el proceso de construcción de software. Está dividido en cuatro partes: modelo
de calidad, métricas externas, métricas internas y calidad de métricas en uso.

SQAE o Software Quality Assessment Exercise: orientado principalmente a realizar evaluación por terceros que no
están directamente involucrados con el desarrollo, siguiendo tres capas: área, factor y atributo de calidad.
Modelos a nivel de producto
WebQEM: es una metodología de evaluación de calidad de sitios Web (Web-site Quality Evaluation method), diseñada
para la evaluación siguiendo seis fases: planificación y programación de la evaluación de calidad, definición y
especificación de requerimientos de calidad, definición e implementación de la evaluación elemental, definición e
implementación de la evaluación global, análisis de resultados, conclusión y documentación, validación de métricas.

ISO 25000: También llamadas como SQuaRE, cuyo propósito es guiar el desarrollo con los requisitos y la evaluación de
atributos de calidad, principalmente: la adecuación funcional, eficiencia de desempeño, compatibilidad , capacidad de uso,
Habilidad, seguridad, mantenibilidad y portabilidad.
 Atributos de Calidad
Un atributo de calidad es una propiedad medible de un sistema, que indica qué tan
bien el sistema satisface las necesidades de las partes interesadas.

A los atributos de calidad también se les conoce como:

● Requerimientos no funcionales.
● Características de arquitectura.
● Propiedades de calidad.

Hay dos categorías de atributos de calidad en los que nos centramos. La primera es
la que describe alguna propiedad del sistema en tiempo de ejecución, como la
disponibilidad, el rendimiento o la facilidad de uso. El segundo es el que describe
alguna propiedad del desarrollo del sistema, como la modificabilidad o la capacidad
de prueba.
Atributos de Calidad
Arquitectura y Requisitos
1. Requisitos funcionales. Estos requisitos establecen qué debe hacer el sistema y cómo debe comportarse o
reaccionar ante los estímulos de tiempo de ejecución.

2. Requisitos de atributos de calidad. Estos requisitos son las calificaciones de los requisitos funcionales o del
producto en general. Una calificación de un requisito funcional es un elemento tal como qué tan rápido se debe
realizar la función, o qué tan resistente debe ser a una entrada errónea. Una calificación del producto general es
un elemento como el tiempo para implementar el producto o una limitación de los costos operativos.

3. Restricciones. Una restricción es una decisión de diseño con cero grados de libertad. Es decir, es una
decisión de diseño que ya se ha tomado.
Funcionalidad
Functionality

La funcionalidad es la capacidad del sistema para realizar el trabajo para el cual fue diseñado. De todos
los requisitos, la funcionalidad tiene la relación más extraña con la arquitectura.

La funcionalidad no determina la arquitectura. Es decir, dado un conjunto de funcionalidades requeridas,

no hay un final para las arquitecturas que podría crear para satisfacer esa funcionalidad.

¿hay operaciones que el software podría realizar internamente y sin embargo hay que hacerlas “a mano”
o en otras aplicaciones?
¿son muy limitadas o incompletas las funciones que realiza el software?
¿resuelve casi todos los problemas de operatividad y gestión de la información?
Funcionalidad
La funcionalidad y los atributos de calidad son ortogonales.

● La funcionalidad es la capacidad de un sistema para realizar la tarea para el cual fue

implementado. Ejemplo: un ATM que dispensa dinero
● Un diseño puede cumplir con la funcionalidad deseada y fallar a la hora de satisfacer sus
requerimientos de calidad. Ejemplo: un ATM de cartón
● Los sistemas se descomponen en componentes (módulos) a fin de satisfacer objetivos adicionales
a la funcionalidad. Ejemplo: en un ATM, componentes separados para manejar el lector de tarjetas,
el dispensador de dinero, la impresora, etc.
● Existe cierto trade-offs (compromiso) entre funcionalidad y atributos de calidad. No cualquier nivel
de un atributo de calidad es compatible con cualquier funcionalidad
Disponibilidad
Availability

La disponibilidad se refiere a una propiedad de software que está allí y lista para llevar a cabo su tarea
cuando la necesita. Esta es una perspectiva amplia y abarca lo que normalmente se llama confiabilidad,
la cual es la capacidad de evitar fallas que son más frecuentes y más graves de lo que es aceptable.

La definición de disponibilidad como un aspecto de confiabilidad es la siguiente: "La disponibilidad se

refiere a la capacidad de un sistema para enmascarar o reparar fallas, de modo que el período de
interrupción acumulativa del servicio no exceda un valor requerido durante un intervalo de tiempo
específico".
Disponibilidad
Escenario general

• Fuente de estímulo . Diferenciamos entre orígenes internos y externos de fallas o fallas porque la respuesta
deseada del sistema puede ser diferente.

• Estímulo . Se produce un fallo de una de las siguientes clases:

• Omisión . Un componente no responde a una entrada.
• Crash . El componente sufre repetidamente fallas de omisión.
• Tiempo . Un componente responde pero la respuesta es temprana o tardía.
• Respuesta . Un componente responde con un valor incorrecto.

• Artefacto. Esto especifica el recurso que se requiere que esté altamente disponible, como un procesador, canal
de comunicación, proceso o almacenamiento.

• Medio ambiente . El estado del sistema cuando ocurre la falla o falla también puede afectar la respuesta del
sistema deseada.
Disponibilidad
Escenario general

• Respuesta . Hay una serie de posibles reacciones a una falla del sistema. Primero, la falla debe ser detectada
y aislada (correlacionada) antes de que cualquier otra respuesta sea posible. Después de que se detecte la falla,
el sistema debe recuperarse de ella.

• Medida de respuesta . La medida de respuesta puede especificar un porcentaje de disponibilidad, o puede

especificar un tiempo para detectar la falla, tiempo para reparar la falla, tiempos o intervalos de tiempo durante
los cuales el sistema debe estar disponible, o la duración por la cual el sistema debe estar disponible.
Interoperabilidad
Interoperability

La interoperabilidad se refiere a la capacidad de los sistemas para intercambiar información de manera útil. Es
posible que estos sistemas se hayan construido con la intención de intercambiar información, pueden ser
sistemas existentes que se desean intercambiar información o pueden proporcionar servicios generales sin
conocer los detalles de los sistemas que desean utilizar esos servicios.

Estas son algunas de las razones por las que podría querer que los sistemas interoperen:
• Su sistema proporciona un servicio para ser utilizado por una colección de sistemas desconocidos. Estos
sistemas necesitan interoperar con su sistema aunque no sepa nada sobre ellos.
• Estás construyendo capacidades a partir de sistemas existentes. Por ejemplo, uno de los sistemas existentes
es responsable de detectar su entorno, otro es responsable de procesar los datos sin procesar, un tercero es
responsable de interpretar los datos y el último es responsable de producir y distribuir una representación de lo
que se detectó.
Interoperabilidad
Escenario general

• Fuente de estímulo . Un sistema inicia una solicitud para interoperar con otro sistema.
• Estímulo . Una solicitud para intercambiar información entre sistemas.
• Artefactos . Los sistemas que deseen interoperar.
• Medio ambiente . Los sistemas que desean interoperar se descubren en tiempo de ejecución o se conocen
antes del tiempo de ejecución.
• Respuesta . La solicitud de interoperar resulta en el intercambio de información. La información es entendida
por la parte receptora de manera sintáctica y semántica. Alternativamente, la solicitud es rechazada y las
entidades apropiadas son notificadas. En cualquier caso, la solicitud puede ser registrada.
• Medida de respuesta . El porcentaje de intercambios de información procesados correctamente o el porcentaje
de intercambios de información rechazados correctamente.
Interoperabilidad
Escenario general
Modificabilidad
Modifiability

La modificabilidad se relaciona con el cambio y el costo en tiempo o dinero de realizar un cambio,

incluida la medida en que esta modificación afecta otras funciones o atributos de calidad.

La modificabilidad tiene que ver con el cambio, y nuestro interés en él se centra en el costo y el riesgo
de realizar cambios. Para planificar la modificabilidad, un arquitecto debe considerar cuatro preguntas:
• ¿Qué puede cambiar?
• ¿Cuál es la probabilidad del cambio?
• ¿ Cuándo se hace el cambio y quién lo hace?
• ¿Cuál es el costo del cambio?
Modificabilidad
Escenario general

• Fuente de estímulo. Esta parte especifica quién realiza el cambio: el desarrollador, un administrador del
sistema o un usuario final.
• Estímulo . Esta parte especifica el cambio a realizar. Un cambio puede ser la adición de una función, la
modificación de una función existente o la eliminación de una función. (Para esta categorización, consideramos
que corregir un defecto es cambiar una función, que presumiblemente no funcionó correctamente como
resultado del defecto). También se puede hacer un cambio en las cualidades del sistema: hacerlo más sensible,
aumentar su capacidad de respuesta. disponibilidad, y así sucesivamente. La capacidad del sistema también
puede cambiar. Acomodar a un número creciente de usuarios simultáneos es un requisito frecuente. Finalmente,
pueden ocurrir cambios para adaptarse a nuevas tecnologías de algún tipo, la más común de las cuales es la de
trasladar el sistema a un tipo diferente de computadora o red de comunicación.
• Artefacto . Esta parte especifica qué se va a cambiar: componentes o módulos específicos, la plataforma del
sistema, su interfaz de usuario, su entorno u otro sistema con el que interactúa
Modificabilidad
Escenario general

• Artefacto . Esta parte especifica qué se va a cambiar: componentes o módulos específicos, la plataforma del
sistema, su interfaz de usuario, su entorno u otro sistema con el que interactúa.
• Medio ambiente . Esta parte especifica cuándo se puede realizar el cambio: tiempo de diseño, tiempo de
compilación, tiempo de compilación, tiempo de inicio o tiempo de ejecución.
• Respuesta . Realice el cambio, pruébelo y desplácelo.
• Medida de respuesta. Todas las respuestas posibles toman tiempo y cuestan dinero;
Rendimiento
Performance

Rendimiento, es decir: se trata del tiempo y la capacidad del sistema de software para cumplir con los
requisitos de tiempo. Cuando ocurren eventos (interrupciones, mensajes, solicitudes de usuarios u otros
sistemas, o eventos de reloj que marcan el paso del tiempo), el sistema, o algún elemento del sistema,
debe responder a ellos a tiempo. La esencia de la discusión del rendimiento es caracterizar los eventos
que pueden ocurrir (y cuándo pueden ocurrir) y la respuesta basada en el tiempo del sistema o elemento
a esos eventos.

El rendimiento a menudo está vinculado a la escalabilidad, es decir, aumenta la capacidad de trabajo de

su sistema, mientras sigue teniendo un buen desempeño. Técnicamente, la escalabilidad hace que su
sistema sea fácil de cambiar de una manera particular, y también lo es un tipo de modificabilidad
Rendimiento
Escenario General

• Fuente de estímulo. Los estímulos llegan de fuentes externas (posiblemente múltiples) o internas.
• Estímulo . Los estímulos son las llegadas del evento. El patrón de llegada puede ser periódico,
estocástico o esporádico, caracterizado por parámetros numéricos.
• Artefacto . El artefacto es el sistema o uno o más de sus componentes.
• Medio ambiente . El sistema puede estar en varios modos operativos, como normal, emergencia, carga
máxima o sobrecarga.
• Respuesta . El sistema debe procesar los eventos que llegan. Esto puede causar un cambio en el
entorno del sistema (por ejemplo, del modo normal al modo de sobrecarga).
• Medida de respuesta. Las medidas de respuesta son el tiempo que lleva procesar los eventos que
llegan (latencia o fecha límite), la variación en este tiempo (jitter), la cantidad de eventos que se pueden
procesar dentro de un intervalo de tiempo particular (rendimiento) o una caracterización de los eventos
que no pueden ser procesados (tasa de error).
Rendimiento
Performance
Seguridad
Security

La seguridad es una medida de la capacidad del sistema para proteger los datos y la información de
accesos no autorizados a la vez que proporciona acceso a personas y sistemas autorizados.

El enfoque más simple para caracterizar la seguridad tiene tres características: confidencialidad,
integridad y disponibilidad (CIA):
1. Confidencialidad es la propiedad de que los datos o servicios están protegidos contra el acceso no
autorizado. Por ejemplo, un pirata informático no puede acceder a sus declaraciones de impuestos
sobre la renta en una computadora del gobierno.
2. La integridad es la propiedad de que los datos o servicios no están sujetos a manipulación no
autorizada. Por ejemplo, su calificación no ha cambiado desde que su instructor la asignó.
3. La disponibilidad es la propiedad de que el sistema estará disponible para uso legítimo. Por ejemplo,
un ataque de denegación de servicio no le impedirá pedir un libro de una librería en línea.
Seguridad
Entorno General

• Fuente de estímulo . La fuente del ataque puede ser un humano u otro sistema.
• Estímulo. El estímulo es un ataque. Caracterizamos esto como un intento no autorizado de mostrar
datos, cambiar o eliminar datos, acceder a servicios del sistema, cambiar el comportamiento del sistema
o reducir la disponibilidad.
• Artefacto . El objetivo del ataque puede ser los servicios del sistema, los datos que contiene o los datos
producidos o consumidos por el sistema.
• Medio ambiente . El ataque puede ocurrir cuando el sistema está en línea o fuera de línea, ya sea
conectado o desconectado de una red, ya sea detrás de un firewall o abierto a una red, completamente
operativo, parcialmente operativo o no operativo.
Seguridad
Entorno General

• Respuesta. El sistema debe garantizar que las transacciones se realicen de manera tal que los datos o
servicios estén protegidos contra el acceso no autorizado; los datos o servicios no están siendo
manipulados sin autorización; las partes en una transacción son identificadas con seguridad; las partes
en la transacción no pueden repudiar sus implicaciones; y los datos, recursos y servicios del sistema
estarán disponibles para uso legítimo.
El sistema también debe realizar un seguimiento de las actividades dentro de él mediante el registro de
acceso o modificación; intentos de acceso a datos, recursos o servicios; y notificar a las entidades
apropiadas (personas o sistemas) cuando se está produciendo un ataque aparente.
• Medida de respuesta . Las medidas de la respuesta de un sistema incluyen cuánto se compromete un
sistema cuando se compromete un componente o un valor de datos en particular, cuánto tiempo pasó
antes de que se detectara un ataque, cuántos ataques se resistieron, cuánto tiempo tomó recuperarse
de un ataque exitoso, y cuánta información fue vulnerable a un ataque en particular.
Seguridad
Testabilidad
Testability

La capacidad de prueba del software se refiere a la facilidad con la que se puede hacer que el software
demuestre sus fallas a través de pruebas (típicamente basadas en la ejecución). Específicamente, la
capacidad de prueba se refiere a la probabilidad, asumiendo que el software tiene al menos una falla,
que fallará en su próxima ejecución de prueba.

Intuitivamente, un sistema es comprobable si "abandona" sus fallas fácilmente. Si una falla está
presente en un sistema, queremos que falle durante la prueba lo más rápido posible.
Testabilidad
Entorno General

• Fuente de estímulo. Las pruebas son realizadas por probadores de unidades, probadores de
integración o probadores de sistemas (en el lado de la organización en desarrollo), o probadores de
aceptación y usuarios finales (por el lado del cliente). La fuente podría ser humana o un probador
automatizado.
• Estímulo . Se ejecuta un conjunto de pruebas debido a la finalización de un incremento de codificación
como una capa de clase o un servicio, la integración completa de un subsistema, la implementación
completa de todo el sistema o la entrega del sistema al cliente.
• Artefacto . Una unidad de código (correspondiente a un módulo en la arquitectura), un subsistema o
todo el sistema es el artefacto que se está probando.
• Medio ambiente . La prueba puede realizarse en el momento del desarrollo, en el momento de la
compilación, en el momento del despliegue o mientras el sistema se está ejecutando (tal vez en uso de
rutina). El entorno también puede incluir el arnés de prueba o los entornos de prueba en uso.
Testabilidad
Entorno General

• Respuesta . El sistema se puede controlar para realizar las pruebas deseadas y se pueden observar
los resultados de la prueba.
• Medida de respuesta . Las medidas de respuesta están destinadas a representar la facilidad con la que
un sistema en prueba "abandona" sus fallas.
Usabilidad
Usability

La usabilidad se relaciona con lo fácil que es para el usuario realizar una tarea deseada y el tipo de
asistencia al usuario que proporciona el sistema. A lo largo de los años, un enfoque en la facilidad de
uso se ha revelado como una de las formas más económicas y sencillas de mejorar la calidad de un
sistema (o, más precisamente, la percepción de calidad del usuario).

La usabilidad comprende las siguientes áreas:

• Funciones del sistema de aprendizaje
• Uso eficiente de un sistema
• Minimizar el impacto de los errores
• Adaptar el sistema a las necesidades del usuario
• Incremento de la confianza y satisfacción
Usabilidad
Entorno General

• Fuente de estímulo. El usuario final (que puede estar en un rol especializado, como un administrador del
sistema o de la red) es siempre la fuente del estímulo para la usabilidad.
• Estímulo . El estímulo es que el usuario final desea utilizar un sistema de manera eficiente, aprender a usarlo,
minimizar el impacto de los errores, adaptar el sistema o configurar el sistema.
• Medio ambiente. Las acciones del usuario que conciernen a la facilidad de uso siempre ocurren en el tiempo
de ejecución o en el tiempo de configuración del sistema.
• Artefacto . El artefacto es el sistema o la parte específica del sistema con el que el usuario está interactuando.
• Respuesta . El sistema debe proporcionar al usuario las funciones necesarias o anticiparse a las necesidades
del usuario.
• Medida de respuesta. La respuesta se mide por el tiempo de la tarea, la cantidad de errores, la cantidad de
tareas realizadas, la satisfacción del usuario, el conocimiento del usuario, la relación entre las operaciones
exitosas y las operaciones totales, o la cantidad de tiempo o datos perdidos cuando se produce un error.
Usabilidad
Variabilidad
Variability

La variabilidad es una forma especial de modificabilidad. Se refiere a la capacidad de un sistema y sus

artefactos de soporte, tales como requisitos, planes de prueba y especificaciones de configuración para
admitir la producción de un conjunto de variantes que difieren entre sí en una forma planificada de
antemano. La variabilidad es un atributo de calidad especialmente importante en una línea de productos
de software, donde significa la capacidad de un activo central para adaptarse a los usos en los
diferentes contextos de productos que se encuentran dentro del alcance de la línea de productos. El
objetivo de la variabilidad en una línea de productos de software es facilitar la creación y el
mantenimiento de productos en la línea de productos durante un período de tiempo. Los escenarios de
variabilidad tratarán el tiempo de unión de la variación y el tiempo de las personas para lograrlo.
Portabilidad
Portability

La portabilidad es también una forma especial de modificabilidad. La portabilidad se refiere a la facilidad

con la que el software que se creó para ejecutarse en una plataforma se puede cambiar para ejecutarse
en una plataforma diferente. La portabilidad se logra al minimizar las dependencias de la plataforma en
el software, aislando las dependencias en ubicaciones bien identificadas y escribiendo el software para
que se ejecute en una "máquina virtual" que encapsule todas las dependencias de la plataforma. Los
escenarios que describen la portabilidad tienen que ver con mover el software a una nueva plataforma al
no gastar más de un cierto nivel de esfuerzo o al contar el número de lugares en el software que
tendrían que cambiar.
Distribución del desarrollo
Development Distributability

La distribución del desarrollo es la calidad del diseño del software para soportar el desarrollo de software
distribuido. Muchos sistemas en estos días se desarrollan utilizando equipos distribuidos globalmente.
Un problema que debe superarse cuando se desarrolla con equipos distribuidos es coordinar sus
actividades. El sistema debe diseñarse de modo que se minimice la coordinación entre los equipos. Esta
coordinación mínima debe lograrse tanto para el código como para el modelo de datos. Los equipos que
trabajan en módulos que se comunican entre sí pueden necesitar negociar las interfaces de esos
módulos. Cuando un módulo es utilizado por muchos otros módulos, cada uno desarrollado por un
equipo diferente, la comunicación y la negociación se vuelven más complejas y onerosas. Se aplican
consideraciones similares para el modelo de datos.
Escalabilidad
Scalability

Dos tipos de escalabilidad son la escalabilidad horizontal y la escalabilidad vertical. La escalabilidad

horizontal se refiere a agregar más recursos a las unidades lógicas, como agregar otro servidor a un
grupo de servidores. La escalabilidad vertical se refiere a agregar más recursos a una unidad física,
como agregar más memoria a una sola computadora.

En entornos de nube, la escalabilidad horizontal se llama elasticidad.. La elasticidad es una propiedad

que permite a un cliente agregar o eliminar máquinas virtuales del grupo de recursos. Estas máquinas
virtuales están alojadas en una gran colección de más de 10,000 máquinas físicas que son
administradas por el proveedor de la nube. Los escenarios de escalabilidad se ocuparán del impacto de
agregar o eliminar recursos, y las medidas reflejarán la disponibilidad asociada y la carga asignada a los
recursos existentes y nuevos.
Implementación
Deployability

La implementación se refiere a cómo llega un ejecutable a una plataforma de host y cómo se invoca
posteriormente. Algunos de los problemas involucrados en la implementación del software son: ¿Cómo llega
a su host (push, donde las actualizaciones se envían a los usuarios de forma no deseada, o pull, donde los
usuarios deben solicitar actualizaciones de forma explícita)? ¿Cómo se integra en un sistema existente?
¿Se puede hacer esto mientras se está ejecutando el sistema existente? Los sistemas móviles tienen sus
propios problemas en cuanto a cómo se actualizan, debido a las preocupaciones sobre el ancho de banda.

Los escenarios de implementación tratarán con el tipo de actualización (push o pull), la forma de la
actualización (medio, como la descarga de DVD o Internet, y el empaquetado, como ejecutable, aplicación o
complemento), la integración resultante en un Sistema existente, la eficiencia de ejecución del proceso y el
riesgo asociado.
Movilidad
Mobility

La movilidad se ocupa de los problemas de movimiento y los costos de una plataforma (por ejemplo,
tamaño, tipo de pantalla, tipo de dispositivos de entrada, disponibilidad y volumen de ancho de banda y
duración de la batería). Los problemas de movilidad incluyen la administración de la batería, la
reconexión después de un período de desconexión y la cantidad de diferentes interfaces de usuario
necesarias para soportar múltiples plataformas.

Los escenarios tratarán con la especificación de los efectos deseados de la movilidad o las diferentes
posibilidades. Los escenarios también pueden lidiar con la variabilidad, donde el mismo software se
implementa en múltiples plataformas .
Fiabilidad
Reliability

Es un atributo del sistema responsable de la capacidad de continuar funcionando en condiciones

predefinidas. Muy a menudo, el sistema falla debido a la inaccesibilidad de elementos externos, como
bases de datos, sistemas y conexiones de red.

La seguridad no es lo mismo que la fiabilidad. Un sistema puede ser confiable (consistente con su
especificación) pero aún inseguro (por ejemplo, cuando la especificación ignora las condiciones que
conducen a una acción insegura).
Eficiencia
Efficiency

Capacidad de un sistema de software para cumplir su propósito con la mejor utilización posible de todos
los recursos necesarios (tiempo, almacenamiento, canales de transmisión y periféricos).

Conjunto de atributos que influyen en la relación entre el nivel de rendimiento del software y la cantidad
de recursos utilizados en las condiciones establecidas.
Mantenibilidad
Maintainability

La mantenibilidad es la capacidad del sistema para soportar cambios. Los cambios pueden estar
relacionados con nuevos requisitos comerciales o la corrección de errores antiguos y afectar los
componentes del sistema o métodos separados. Además, la capacidad de mantenimiento afecta el
tiempo necesario para restaurar el sistema después de una falla. Las dependencias excesivas entre
componentes tienen un efecto muy negativo en la mantenibilidad. Este atributo afecta no solo a los
procesos de desarrollo, sino también a los procesos de gestión (por ejemplo, dividir los equipos en
partes relacionadas con el producto).