Sesión - 04 - Atributos de Calidad

SESIÓN 04:
Atributos de Calidad
Ingeniería de Sistemas
Arquitectura de Sistemas de Información
Presentation_ID Información confidencial de Cisco 1

Agenda
CAPTURA DE REQUERIMIENTOS
ATRIBUTOS DE CALIDAD
IMPORTANCIA DE LOS ATRIBUTOS DE CALIDAD
CLASIFICACIÓN DE ATRIBUTOS DE CALIDAD

Actividad de Inducción
Es increíble lo fácil que es

hacer software en nuestros
tiempos, pues existen tantas
herramientas, lenguajes y
frameworks que permite que
casi cualquier persona,
incluso con pocos
conocimientos puede
construir un software.
3
Combinado con la gran demanda de empresas que requieren

desarrollo de software, ha provocado el surgimiento de muchas
empresas que se dedican a satisfacer esta demanda, sin embargo, y
a pesar de que crear software es muy fácil, la realidad es que crear
software de calidad es muy difícil.
Ello provoca que una gran

cantidad del software
desarrollado no cumple con las
cuestiones básicas de calidad
exigidas por el cliente, lo que
provoca un gran trabajo de
corrección o incluso, el fracaso total
del proyecto.
4
La pregunta aquí es, ¿por qué construir

software es fácil, pero construir
software de calidad es muy difícil?
La respuesta es más complicada de lo que podría

parecer, sin embargo, la clave del éxito de un
software nace desde las etapas más
tempranas, es decir, desde la toma de
requerimientos, que es cuando nuestro cliente
nos plantea la problemática que busca resolver.
Importante
5
6
I. Captura de Requerimientos
En esta etapa, el cliente nos

indicará los escenarios de
negocio o problemáticas
que tiene el negocio y como
quiere resolverlas, es decir,
“quiero que el sistema haga
esto, quiero que el sistema
haga el otro”.
7
En esta etapa nos enfocamos

en entender los
requerimientos del cliente y
vamos apuntando todo lo que
nos va pidiendo.
Todos estos requerimientos

que nos va solicitando el
cliente de forma explícita y
que están relacionados
directamente a resolver un
problema del negocio los
conocemos como
requerimientos funcionales.
8
Un requerimiento
funcional representa
una característica que
debe tener el sistema,
la cual es por lo general
solicitada de forma
explícita.
9
Podemos decir que, por lo general, cuando se toman

los requerimientos, solo se toman en cuenta los
requerimientos funcionales, es decir, lo que solicita
explícitamente el cliente.
Sin embargo, pasamos por alto todos aquellos
requerimientos implícitos que se leen entre líneas y
que son claves para que un software cumpla con la
calidad adecuada, estos requerimientos son los
requerimientos no funcionales.
10
Los requerimientos no
funcionales son aquellos
que no se refieren
directamente a una
funcionalidad específica del
sistema, si no a las
propiedades del sistema,
como la seguridad,
performance, usabilidad, etc.
11
Los requerimientos no funcionales son

rara vez mencionados por los usuarios,
sobre todo porque no forman parte del
proceso de negocio en sí, aunque son
claramente claves para el éxito del
sistema.
En la arquitectura de software, los

requerimientos no funcionales son
por lo general los atributos de
calidad.
12
II. Atributos de Calidad
Los atributos de calidad son todos aquellos

requerimientos que tiene un impacto en la
arquitectura del software. En otras palabras, son
requisitos arquitectónicamente significativos que
requieren la atención de los arquitectos.
13
II. Atributos de Calidad
No todos los requerimientos no funcionales afectan a

la arquitectura, pero, por otro lado, algunos
requerimientos funcionales pueden tener un impacto
sobre la arquitectura.
Atributos de Calidad son todos

aquellos requerimientos
funcionales o no funcionales
que tiene un impacto directo
sobre la arquitectura del sistema
(requisitos arquitectónicamente
significativos) y que requieren la
atención de un arquitecto.
14
III. Importancia de Atributos de Calidad
Los atributos de calidad

son importantes
porque sirven como
un punto de
referencia que nos
ayuda a evaluar la
calidad de un
sistema, ya que a
medida que cumplimos
con los atributos de
calidad, vamos
cumpliendo con la
calidad general del
sistema.
15
III. Importancia de Atributos de Calidad
Los atributos de calidad pueden

tener un impacto directo sobre
el diseño de la arquitectura, por
lo que es de gran interés para
los arquitectos identificarlos y
diseñar soluciones que cumplan
con todos o la gran mayoría de
ellos.
Por ello, es importante que los atributos

de calidad puedan ser medibles y
comprobables, en otro caso, no se podría
medir la calidad del sistema.
16
IV. Clasificación de los atributos de calidad
Los atributos de calidad observables, los cuales son

todos aquellos que pueden ser observados y validados
simplemente por un usuario final con tan solo utilizar el
sistema
Los atributos de calidad no observables son aquellos
que no se pueden observar simplemente con solo utilizar
el sistema, si no que requiere ser puesto a pruebas o a
un análisis completo para comprobar su cumplimiento.
17
Rendimiento
Usabilidad Seguridad
Observables
Funcionalidad Disponibilidad
18
Modificabilidad
Escabilidad Portabilidad
No
Observables
Testabilidad Reusabilidad
19
Observables
20
IV. Clasificación de los atributos de calidad - Observables
a) Performance (rendimiento): El performance es el

atributo de calidad relacionado con el tiempo en que
tarda un sistema en responder a un estímulo o
evento, de esta forma, el performance busca
determinar si el tiempo de respuesta de un sistema
es adecuado según los requerimientos.
21
Por ejemplo, ¿te ha pasado alguna vez que entras a

una página y tarda mucho en cargar, tanto que
decides mejor cancelar y busca en otra página?,
Esto es un claro ejemplo de que el performance se puede

observar fácilmente, sin embargo, no basta con
determinar si un sistema es rápido o lento según nuestra
propia perspectiva, ya que para cada persona la
sensación de tiempo de carga puede ser diferente, es por
eso que el performance se debe de medir de tal forma
que no quede a la interpretación del usuario.
22
No solo basta que la aplicación

responda rápido con un solo
usuario conectado, si no que
deberá responder rápido aun
cuando tengamos varios
usuarios o procesos
ejecutándose al mismo tiempo,
es por eso que la forma correcta
para medir el performance es,
número de transacciones por
unidad de tiempo, es decir,
cuantas transacciones
podemos procesar en un
tiempo determinado, donde la
unidad de tiempo podrían ser
milisegundos, segundos, minutos,
horas, etc
23
Cuando el tiempo de respuesta

debe de ser medido con exactitud,
se suele implementar lo que se
conoce como SLA (service level
agreement) Acuerdo de Nivel de
Servicio, el cual mediante
herramientas podemos monitorear
para determinar cuando el sistema
está tardando más del tiempo del
esperado por transacción
individual, de esta forma, en el
SLA podemos determinar el
tiempo exacto en el cual el
sistema debe de responder, y
nos alerta cuando el sistema
tarda más de este tiempo.
24
Determinar la causa por las que un sistema tiene mal

performance puede ser complicado, ya que existen muchas
razones que lo pueden provocar, como la latencia, operaciones
de lectura y escritura, velocidad de red/internet, servicios
externos, sobre carga de usuarios/procesos, hardware, etc
25
A pesar de todo esto, al final, al usuario lo único que

le interesará es cuánto tiempo tardar nuestra
aplicación en responder/cargar, por lo que debemos
poner mucho foco en ello, pues esto está
directamente relacionado a la experiencia de
usuario (UX) que le estamos brindando.
26
b) Security (Seguridad): La seguridad es la capacidad

de un sistema para resistir al uso no autorizado, al
mismo tiempo que proporciona sus servicios a
usuarios legítimos. Cualquier intento no autorizado de
acceder al sistema es considerado como un ataque, y
un ataque es cualquier intento de violar la seguridad
del sistema
27
Por ejemplo, cuando nuestro banco bloquea ciertas

transacciones de nuestra tarjeta de crédito, debido a
que identifica un comportamiento inusual en el uso, al
mismo tiempo nos notifica que se realizó una
transacción sospechosa y nos solicita que la
reconozcamos o la rechacemos y de esta forma el
sistema va aprendiendo
28
Algunos de los ataques más frecuentes son:
o Robo de datos: Consiste en robar datos confidenciales

de nuestros clientes para poder ser explotados.
Ejemplos de estos son: datos de las tarjetas de crédito
para realizar compras fraudulentas, robo de datos
personales para extorsionar o venderse, conocer
información privilegiada.
o Denegación de servicio (DoS): Consiste en que el

atacante lanza masivas solicitudes sobre una aplicación
para saturarla e impedir que usuarios legítimos puedan
utilizarla.
29
o Borrado de datos: Consiste en ataques dirigidos a hacer un

daño directo sobre la compañía, borrando datos críticos para
su operación, como base de datos o archivos del sistema.
o Secuestro de información (Ransomware): Son virus que

encriptan la información de nuestro disco con la finalidad de
que paguemos un rescate para desencriptar la información.
o Intermediario (Man-in-the-middle): Este ataque consiste en

interceptar los mensajes entre dos entidades, de tal forma
que el atacante puede ver los mensajes que se envían entre
sí, o incluso, enviar mensajes en nombre de alguno de ellos.
30
o Robo de identidad: Es cuando el atacante se hace

pasar por un usuario legítimo y realiza acciones en su
nombre.
o Software malicioso: Los softwares maliciosos son

todos aquellos virus, troyanos, keyloggers, spyware,
etc, los cuales tiene como objetivo desde solo espiar
al usuario, hasta tomar el control total del equipo.
31
Tener en cuenta…
La mayoría de los ataques exitosos son

causados por descuidos de los usuarios y no
por un hacker que quiebra toda la seguridad,
esto consiste en que los usuarios dejan sus
contraseñas a la vista, las guardan en texto plano,
utilizan la misma para todas sus
aplicaciones/servicios, introducen las contraseñas
en redes no seguras, no utilizan múltiples factores
de autenticación, o simplemente responden mails
de orígenes dudosos con datos importantes
32
Por ello para crear aplicaciones más seguras…

…hay que considerar algunas características que
un sistema seguro debería de tener como:
o No repudio: En una comunicación entre dos partes
(emisor y receptor), ninguna de las partes podrá negar
una transacción, de tal forma que el emisor no podrá
negar que envió un mensaje al receptor, porque el
receptor tendrá pruebas de que si lo hizo y visceversa.
o Autenticidad: La autenticidad es la capacidad de un

sistema para detectar quien está del otro lado, y
asegurarse de que la persona que está del otro lado es
quien dice ser, de esta forma, prevenimos enviar
información sensible a un impostor.
33
o Confidencialidad: La confidencialidad consiste en que la

información, ya sea almacenada, transmitida por la red o
almacenada en memoria, solo esté disponible para
aquellas personas que estén autorizada para acceder a
dicha información.
o Integridad: La integridad es básicamente la capacidad de

un sistema para detectar cuando un mensaje ha sido
alterado durante su transmisión. El sistema deberá poder
validar que el mensaje recibido no ha sido alterado desde
su creación. Las firmas digitales es una forma adecuada de
validar la integridad de un mensaje.
34
c) Availability (disponibilidad): Este atributo de calidad

hace referencia al tiempo al que está operable un
sistema para realizar la tarea para la que fue diseñada.
En pocas palabras, es el tiempo que la aplicación está
funcionando.
35
d) Functionality (funcionalidad): La funcionalidad es la

capacidad del sistema para realizar el trabajo para el cual fue
diseñado.
En este sentido, a este
atributo no le interesa
como es que se
construyamos el sistema,
siempre y cuando cumpla
con su trabajo, esto quiere
decir que la aplicación
podría ser un solo
componente (monolítico),
sin una estructura concreta
o una división de
responsabilidades.
36
e) Usability (Usabilidad): La usabilidad mide el grado en el

que un usuario especifico puede usar un software para
lograr una serie de objetivos cuantificados.
La usabilidad es uno de los atributos clave para el éxito de
nuestro proyecto, pues de alguna forma mide el nivel de
satisfacción del usuario.
37
No Observables
38
IV. Clasificación de los atributos de calidad – No Observables
a) Modificabilidad: Corresponde al costo y riesgo de realizar un

cambio sobre un sistema existente. Es normal que los sistemas
cambien o sean modificados durante toda su vida útil, ya sea
para adaptarse a las nuevas necesidades del negocio, cambio
en las tendencias del mercado, adaptar nuevas tecnologías,
implementar nuevos protocolos, corregir temas de seguridad,
mejorar la usabilidad, ajustar el performance, etc.
39
Un arquitecto deberá plantearse las siguientes

preguntas con la finalidad de planificar la
modificabilidad del sistema
o ¿Qué puede cambiar?

o ¿Cuál es la probabilidad del cambio?
o ¿Quién debe hacer el cambio?
o ¿Cuál es el costo del cambio?
40
b) Portabilidad: Es la capacidad de un software

para adaptarse a una plataforma diferente para
la que se diseñó originalmente. La portabilidad se
puede dar a otro nivel, por ejemplo, que nuestras
aplicaciones corran en más de un servidor de
aplicaciones, o que puede ser interpretado por
diferentes máquinas virtuales, o protocolos de
comunicación independientes de la plataforma, etc
41
La arquitectura que siguen plataformas con

máquinas virtuales
42
Ser portable no significa que nuestro software

debe ejecutar en todos los sistemas
operativos, sino que podemos limitar el
número de sistemas operativos a los cuales
queremos llevar la portabilidad
43
c) Reusabilidad: La reusabilidad es la capacidad de

una unidad de software para poder ser reutilizada
en más de un programa de software,
44
Un componente reutilizable debe de tener ciertas características

para considerarse reutilizable, como lo son:
o Modular: el componente en si debe de ser diseñado para ser

solo una parte de la solución, lo cual implica que pueda ser
importado como librería o ser consumido como un servicio.
o Responsabilidad única: Debe ser diseñado para realizar una

sola tarea, o un conjunto de tareas relacionadas.
o Alta cohesión: El componente debe agrupar solo clases,

métodos u operaciones que estén enfocadas únicamente a
resolver la misma problemática.
o Bajo acoplamiento: Debemos evitar al máximo el

acoplamiento de nuestro componente con otras
dependencias.
45
o Fácil de utilizar: Debe diseñarse para que sea fácil de

utilizar, tenga documentación y las operaciones y objetos
expuestos sean lo bastante descriptivos.
o Encapsulado: La encapsulación es muy importante, pues

evita que gente sin conocimiento modifique propiedades que
podrían afectar el funcionamiento, por lo que, en su lugar,
debemos exponer operaciones de alto nivel que puedan ser
consumidas fácilmente por los usuarios.
46
Importante
Un componente se puede reutilizar
básicamente de dos formas,
importarlos como librería, o
consumiéndolo como un recurso
externo, en los dos casos tenemos una
reutilización, sin embargo, tiene
diferentes implicaciones
47
Caso: Dependencias importadas
48
Caso: Dependencias con servicios
49
d) Testabilidad: Es la capacidad para hacer fallar lo

más simplemente posible un componente de
software por medio de pruebas.
La testabilidad se logra desarrollando pequeñas
unidades de software que puedan ser probadas
de forma individual, de tal forma que en lugar de
tener que ejecutar una serie de pasos para llegar a
una funcionalidad determinada.
50
Pruebas Típicas de Software
51
1
En este primer ejemplo, se da la forma en que
típicamente se realizan las pruebas, en el cual un
usuario le envía ciertos parámetros a un macro
proceso. En este escenario, el macro proceso
recibe los parámetros de entrada y ejecuta varios
micro procesos que en su conjunto terminan
haciendo la tarea principal y dando como resultado
una salida, pero NO se tiene forma de probar de
forma individual cada micro proceso.
52
Adecuada ejecución de las pruebas
53
2
En el segundo ejemplo se realizan pruebas a
nivel de objetos, operaciones o
procedimientos, los cuales requieren un nivel
técnico, es por ello que muchas de estas
pruebas las tendrá que realizar el mismo
desarrollador y son conocidas como pruebas
unitarias
54
La idea es que el
programador sea el
responsable de asegurarse
de que todas las unidades
de software liberadas
hayan pasado por una
serie de pruebas y con ello
garantizar la calidad del
software liberado. Probar las
unidades de software
garantiza que el software
funcionará coherentemente
sin importar los inputs que
reciba, incluso en desarrollos
futuros para los cuales quizás
no fue pensado en el inicio.
55
Otra de las ventaja de las

pruebas unitarias es que
son programadas y se
pueden ejecutar en
cualquier momento,
incluso como una terea
posterior a la compilación
o el despliegue, de esta
forma, no tenemos que
repetir las pruebas de
forma manual cada vez
que hagamos un cambio.
56
La siguiente imagen representa la pirámide de pruebas, la cual es

una de las gráficas más aceptadas con respecto a la importancia y
tipos de pruebas:
57
La realidad es que mucho del software que se

desarrollan no tiene pruebas unitarias, lo que
provoca una gráfica invertida o también llamada
de “cono de nieve”, en la cual terminamos
detectando la gran cantidad de las fallas en la UI, lo
que tiene un costo altísimo, tanto económico como
de tiempo, y ni hablar del desgaste de los usuario o
inconformidad del cliente
58
d) Escalabilidad: Es la capacidad del software para

adaptarse a las necesidades de rendimiento a
medida que el número de usuarios crece, las
transacciones aumentan y la base de datos
empieza a sufrir desgasto del performance
59
TAREA :TÉCNICAS DE CAPTURA DE
REQUERIMIENTOS
60
GRACIAS
Ingeniería de Sistemas
Arquitectura de Sistemas de Información

Sesión - 04 - Atributos de Calidad

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sesión - 04 - Atributos de Calidad

Cargado por

Copyright:

Formatos disponibles

SESIÓN 04:

Presentation_ID Información confidencial de Cisco 1

IMPORTANCIA DE LOS ATRIBUTOS DE CALIDAD

CLASIFICACIÓN DE ATRIBUTOS DE CALIDAD

Presentation_ID Información confidencial de Cisco 2

Es increíble lo fácil que es

Combinado con la gran demanda de empresas que requieren

Ello provoca que una gran

La pregunta aquí es, ¿por qué construir

La respuesta es más complicada de lo que podría

En esta etapa, el cliente nos

En esta etapa nos enfocamos

Todos estos requerimientos

Podemos decir que, por lo general, cuando se toman

Los requerimientos no funcionales son

En la arquitectura de software, los

Los atributos de calidad son todos aquellos

No todos los requerimientos no funcionales afectan a

Atributos de Calidad son todos

Los atributos de calidad

Los atributos de calidad pueden

Por ello, es importante que los atributos

Los atributos de calidad observables, los cuales son

a) Performance (rendimiento): El performance es el

Por ejemplo, ¿te ha pasado alguna vez que entras a

Esto es un claro ejemplo de que el performance se puede

No solo basta que la aplicación

Cuando el tiempo de respuesta

Determinar la causa por las que un sistema tiene mal

A pesar de todo esto, al final, al usuario lo único que

b) Security (Seguridad): La seguridad es la capacidad

Por ejemplo, cuando nuestro banco bloquea ciertas

Algunos de los ataques más frecuentes son:

o Robo de datos: Consiste en robar datos confidenciales

o Denegación de servicio (DoS): Consiste en que el

o Borrado de datos: Consiste en ataques dirigidos a hacer un

o Secuestro de información (Ransomware): Son virus que

o Intermediario (Man-in-the-middle): Este ataque consiste en

o Robo de identidad: Es cuando el atacante se hace

o Software malicioso: Los softwares maliciosos son

La mayoría de los ataques exitosos son

Por ello para crear aplicaciones más seguras…

o Autenticidad: La autenticidad es la capacidad de un

o Confidencialidad: La confidencialidad consiste en que la

o Integridad: La integridad es básicamente la capacidad de

c) Availability (disponibilidad): Este atributo de calidad

d) Functionality (funcionalidad): La funcionalidad es la

e) Usability (Usabilidad): La usabilidad mide el grado en el

a) Modificabilidad: Corresponde al costo y riesgo de realizar un

Un arquitecto deberá plantearse las siguientes

o ¿Qué puede cambiar?

b) Portabilidad: Es la capacidad de un software

La arquitectura que siguen plataformas con

Ser portable no significa que nuestro software

c) Reusabilidad: La reusabilidad es la capacidad de

Un componente reutilizable debe de tener ciertas características

o Modular: el componente en si debe de ser diseñado para ser

o Responsabilidad única: Debe ser diseñado para realizar una

o Alta cohesión: El componente debe agrupar solo clases,

o Bajo acoplamiento: Debemos evitar al máximo el

o Fácil de utilizar: Debe diseñarse para que sea fácil de

o Encapsulado: La encapsulación es muy importante, pues