SES - UML

Vista previa del material en texto

UML - MODELO DE 
DATOS - METRICAS
Arquitectura de Sistemas de Información
Antonio Noronha Gómez
Unidad 3
¿Qué es UML?
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un 
lenguaje de modelado visual común y semántica y sintácticamente 
rico para la arquitectura, el diseño y la implementación de sistemas 
de software complejos, tanto en estructura como en 
comportamiento.
Es comparable a los planos usados en otros campos y consiste en 
diferentes tipos de diagramas. En general, los diagramas UML 
describen los límites, la estructura y el comportamiento del sistema y 
los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas 
que se pueden usar para generar código en diversos lenguajes usando 
los diagramas UML. UML guarda una relación directa con el análisis y 
el diseño orientados a objetos.
Observa el siguiente ejemplo de un diagrama UML. Proporciona un flujo 
paso a paso de cómo funciona un sistema de cajeros automáticos. A 
partir de este diagrama, podemos trabajar en el software back-end e 
incluso hacer que otros se asemejen en funcionamiento.
¿Qué es UML?
¿Por qué necesitamos UML?
• Proporcionan una representación visual del problema o de todo el sistema.
De este modo, incluso alguien que no sea desarrollador puede entender
cómo funciona el sistema.
• Los diagramas UML también desempeñan un papel fundamental en la
resolución de problemas. Podemos representar un problema del mundo
real y encontrar gradualmente la forma de resolverlo.
• Como estos diagramas son sencillos de comprender, no es necesario tener
conocimientos previos para saber cómo funciona una entidad o cómo fluye
un proceso.
• Al utilizar un diagrama UML holístico, todo el equipo de desarrollo de
software puede colaborar y trabajar en conjunto.
• Tienen muchas aplicaciones en la programación orientada a objetos,
desarrollo web, desarrollo de prototipos, análisis de negocios, entre otros.
Función en el modelado y diseño 
orientados a objetos
Existen cuatro categorías de modelos para la resolución de problemas: 
lenguajes imperativos, funcionales, declarativos y orientados a objetos (OOP).
En los lenguajes orientados a objetos, los algoritmos se expresan definiendo 
'objetos' y haciendo que los objetos interactúen entre sí. Esos objetos son cosas 
que deben ser manipuladas y existen en el mundo real. Pueden ser edificios, 
artefactos sobre un escritorio o seres humanos.
Los lenguajes orientados a objetos dominan el mundo de la programación 
porque modelan los objetos del mundo real. UML es una combinación de varias 
notaciones orientadas a objetos: diseño orientado a objetos, técnica de 
modelado de objetos e ingeniería de software orientada a objetos.
UML usa las fortalezas de estos tres enfoques para presentar una metodología 
más uniforme que sea más sencilla de usar. UML representa buenas prácticas 
para la construcción y documentación de diferentes aspectos del modelado de 
sistemas de software y de negocios.
La historia y los orígenes de UML
"The Three Amigos" (los tres amigos) de la ingeniería de software, como 
se los conocía, habían desarrollado otras metodologías. Se asociaron para 
brindar claridad a los programadores creando nuevos estándares. La 
colaboración entre Grady, Booch y Rumbaugh fortaleció los tres métodos 
y mejoró el producto final.
Los esfuerzos de estos pensadores derivaron en la publicación de los 
documentos UML 0.9 y 0.91 en 1996. Pronto se hizo evidente que varias 
organizaciones, incluidas Microsoft, Oracle e IBM, consideraron que UML 
era esencial para su propio desarrollo de negocios. Ellos, junto con 
muchas otras personas y compañías, establecieron los recursos 
necesarios para desarrollar un lenguaje de modelado hecho y derecho. 
"Los tres amigos" publicaron la Guía del usuario para el Lenguaje 
Unificado de Modelado en 1999, y una actualización que incluye 
información sobre UML 2.0 en la segunda edición de 2005.
OMG - Object Management 
Group
Es un consorcio internacional sin fines de lucro y de membresía abierta para 
estándares tecnológicos, fundado en 1989. Los estándares de OMG son 
promovidos por proveedores, usuarios finales, instituciones académicas y 
agencias gubernamentales. Los grupos de trabajo de OMG desarrollan 
estándares de integración empresarial para una amplia gama de tecnologías 
y una gama incluso más amplia de industrias. Los estándares de modelado 
de OMG, incluidos UML y Model Driven Architecture® (MDA®), permiten un 
eficaz diseño visual, ejecución y mantenimiento de software y otros 
procesos.
OMG supervisa la definición y el mantenimiento de las especificaciones de 
UML. Esta supervisión ofrece a los ingenieros y programadores la capacidad 
de usar un lenguaje para muchos propósitos durante todas las etapas del 
ciclo de vida del software en sistemas de cualquier tamaño.
La finalidad de UML según OMG
El OMG define los propósitos de UML de la siguiente manera:
• Brindar a arquitectos de sistemas, ingenieros y desarrolladores de 
software las herramientas para el análisis, el diseño y la implementación 
de sistemas basados en software, así como para el modelado de procesos 
de negocios y similares.
• Hacer progresar el estado de la industria permitiendo la interoperabilidad 
de herramientas de modelado visual de objetos. No obstante, para 
habilitar un intercambio significativo de información de modelos entre 
herramientas, se requiere de un acuerdo con respecto a la semántica y 
notación.
UML cumple con los siguientes requerimientos:
• Establecer una definición formal de un metamodelo común basado en el 
estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del 
UML. La sintaxis abstracta define el conjunto de conceptos de modelado UML, 
sus atributos y sus relaciones, así como las reglas de combinación de estos 
conceptos para construir modelos UML parciales o completos.
La finalidad de UML según OMG
• Brindar una explicación detallada de la semántica de cada concepto de 
modelado UML. La semántica define, de manera independiente a la 
tecnología, cómo los conceptos UML se habrán de desarrollar por las 
computadoras.
• Especificar los elementos de notación de lectura humana para 
representar los conceptos individuales de modelado UML, así como las 
reglas para combinarlos en una variedad de diferentes tipos de 
diagramas que corresponden a diferentes aspectos de los sistemas 
modelados.
• Definir formas que permitan hacer que las herramientas UML cumplan 
con esta especificación. Esto se apoya (en una especificación 
independiente) con una especificación basada en XML de formatos de 
intercambio de modelos correspondientes (XMI) que deben ser 
concretados por herramientas compatibles.
Actualizaciones en UML
UML 2.0 extiende las especificaciones de UML para cubrir más aspectos de 
desarrollo, incluido Agile. La meta era reestructurar y perfeccionar UML de forma 
que la facilidad de uso, la implementación y la adaptación se simplificaran. Estas 
son algunas de las actualizaciones de los diagramas UML:
• UML 2.0 eleva el número de diagramas de 9 a 13, comprende UML 2.1 hasta 
UML 2.5, 2.6, etc. En torno a 2005 se difundió una nueva versión de UML a la 
que podemos denominar UML 2.X. Comprenden varias revisiones..
• UML 3.X: evolución que se espera para UML 2.X.
TIPOS DE DIAGRAMAS EN UML
Diagrama de Objetos
Los Diagramas de Objetos están vinculados con los Diagramas de Clases. Un 
objeto es una instancia de una clase, por lo que un diagrama de objetos 
puede ser visto como una instancia de un diagrama de clases. Los diagramas 
de objetos describen la estructura estática de un sistema en un momento 
particular y son usados para probar la precisión de los diagramas de clases. 
Diagrama de Casos de Usos
Un caso de uso es una descripción de las acciones de un sistema desde el 
punto de vista del usuario. Es una herramienta valiosa dado que es una técnica 
de aciertos y errores para obtener los requerimientos del sistema, justamente 
desde elpunto de vista del usuario. Los diagramas de caso de uso modelan la 
funcionalidad del sistema usando actores y casos de uso. Los casos de uso son 
servicios o funciones provistas por el sistema para sus usuarios
14
Diagrama de Estados
En cualquier momento, un objeto se encuentra en un estado particular, 
la luz está encendida o apagada, el auto en movimiento o detenido, la 
persona leyendo o cantando, etc. . El diagrama de estados UML captura 
esa pequeña realidad. 
15
Diagrama de Secuencias
Los diagramas de clases y los de objetos representan información estática. 
No obstante, en un sistema funcional, los objetos interactúan entre sí, y 
tales interacciones suceden con el tiempo. El diagrama de secuencias UML 
muestra la mecánica de la interacción con base en tiempos.
Diagrama de Actividades
Un diagrama de actividades ilustra la naturaleza dinámica de un 
sistema mediante el modelado del flujo ocurrente de actividad en 
actividad. Una actividad representa una operación en alguna clase 
del sistema y que resulta en un cambio en el estado del sistema. 
Típicamente, los diagramas de actividad son utilizados para modelar 
el flujo de trabajo interno de una operación.
Diagrama de Colaboraciones
El diagrama de colaboraciones describe las interacciones entre los objetos en 
términos de mensajes secuenciados. Los diagramas de colaboración 
representan una combinación de información tomada de los diagramas de 
clases, de secuencias y de casos de uso, describiendo el comportamiento, 
tanto de la estructura estática, como de la estructura dinámica de un 
sistema.
Diagrama de Componentes?
Un diagrama de componentes describe la organización de los 
componentes físicos de un sistema. 
Diagrama de Distribución 
El diagrama de distribución UML muestra la arquitectura física de un 
sistema informático. Puede representar a los equipos y a los 
dispositivos, y también mostrar sus interconexiones y el software que 
se encontrará en cada máquina.
Diagrama de Clases
Los diagramas de clases describen la estructura estática de un sistema. Las 
cosas que existen y que nos rodean se agrupan naturalmente en categorías. 
Una clase es una categoría o grupo de cosas que tienen atributos (propiedades) 
y acciones similares. Un ejemplo puede ser la clase “Aviones” que tiene 
atributos como el “modelo de avión”, “la cantidad de motores”, “la velocidad de 
crucero” y “la capacidad de carga útil”. Entre las acciones de las cosas de esta 
clase se encuentran: “acelerar”, “elevarse”, “girar”, “descender”, “desacelerar”.
Un rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. 
Un diagrama de clases está formado por varios rectángulos de este tipo 
conectados por líneas que representan las asociaciones o maneras en que las 
clases se relacionan entre si.
Base de Datos - Modelo Entidad 
Relación 
Un diagrama entidad-relación, también conocido como modelo entidad relación o 
ERD, es un tipo de diagrama de flujo que ilustra cómo las "entidades", como 
personas, objetos o conceptos, se relacionan entre sí dentro de un sistema. Los 
diagramas ER se usan a menudo para diseñar o depurar bases de datos 
relacionales en los campos de ingeniería de software, sistemas de información 
empresarial, educación e investigación. También conocidos como los ERD o 
modelos ER, emplean un conjunto definido de símbolos, tales como rectángulos, 
diamantes, óvalos y líneas de conexión para representar la interconexión de 
entidades, relaciones y sus atributos. Son un reflejo de la estructura gramatical y 
emplean entidades como sustantivos y relaciones como verbos.
Usos de los diagramas entidad-
relación
• Diseño de bases de datos: los diagramas ER se usan para modelar y diseñar 
bases de datos relacionales, en términos de reglas de negocio y lógicas y en 
términos de la tecnología específica que se implementará. En ingeniería de 
software, un diagrama ER a menudo es un primer paso para determinar los 
requisitos de un proyecto de sistemas de información. También se usa más 
adelante para modelar una base de datos en particular o varias. Una base de 
datos relacional tiene una tabla relacional equivalente y puede expresarse así 
potencialmente, según sea necesario.
• Solución de problemas de bases de datos: los diagramas ER se usan para 
analizar las bases de datos existentes con el fin de hallar y resolver problemas 
de lógica o implementación. Al dibujar un diagrama se debería descubrir dónde 
está el problema.
• Reingeniería de procesos de negocio (BPR): Los diagramas ER ayudan a analizar 
las bases de datos empleadas en la reingeniería de procesos de negocio y en el 
modelado de la configuración de una nueva base de datos.
• Educación: las bases de datos son el método actual de almacenamiento de 
información relacional para propósitos educativos y la posterior 
recuperación. Así, los diagramas ER pueden ser útiles para la planificación 
de esas estructuras de datos.
• Investigación: como hay muchas investigaciones centradas en los datos 
estructurados, los diagramas ER pueden desempeñar un papel 
fundamental en la configuración de bases de datos útiles para analizar los 
datos.
• Sistemas de información empresarial: los diagramas se usan para diseñar o 
analizar las bases de datos relacionales empleadas en procesos de negocio. 
Cualquier proceso de negocio que utilice datos de campo relacionados con 
entidades, acciones e interacción puede beneficiarse potencialmente de 
una base de datos relacional. Puede simplificar procesos, revelar 
información de forma más sencilla y mejorar los resultados.
Usos de los diagramas entidad-
relación
Modelos de datos físicos, lógicos 
y conceptuales
Los modelos de datos y los modelos ER se dibujan típicamente con hasta tres 
niveles de detalle:
• Modelo de datos conceptuales: la visualización de nivel más alto que 
contiene la menor cantidad de detalle. Su valor muestra el alcance global del 
modelo y representa la arquitectura del sistema. Para un sistema de menor 
alcance, quizás no sea necesario dibujarlo. En cambio, se comienza con el 
modelo lógico.
• Modelo de datos lógicos: contiene más detalle que un modelo conceptual. 
Ahora se definen las entidades transaccionales y operativas más detalladas. El 
modelo lógico es independiente de la tecnología en la que se implementará.
• Modelo de datos físicos: uno o más modelos físicos pueden desarrollarse a 
partir de cada modelo lógico. El modelo físico debe mostrar los suficientes 
detalles tecnológicos para producir e implementar la base de datos en 
cuestión.
Limitaciones de los modelos y 
DER
• Exclusivo para datos relacionales: comprende que el propósito es solo 
mostrar las relaciones. Los diagramas ER muestran únicamente la estructura 
relacional.
• Inadecuado para datos no estructurados: a menos que los datos se delineen 
claramente en campos, filas o columnas diferentes, es probable que los 
diagramas ER tengan un uso limitado. Lo mismo sucede con los datos 
semiestructurados, porque solo algunos datos serán útiles.
• Complicaciones al realizar una integración con una base de datos 
existente: usar modelos ER para realizar una integración con bases de datos 
existentes puede ser un desafío debido a las diferentes arquitecturas.
Normalización de Base de Datos
La normalización de una base de datos es la aplicación de una serie de reglas para 
evitar a futuro realizar queries o consultas innecesariamente complejas. En otras 
palabras están enfocadas en eliminar redundancias e inconsistencias de 
dependencia en el diseño de las tablas que creamos para organizar las bases de 
datos.
Una vez que se tenga un diseño preliminar para tu base de datos, puedes aplicar 
reglas de normalización para asegurarte de que las tablas estén estructuradas 
correctamente.
Generalmente, las bases de datos de procesamiento de transacciones en 
línea (OLTP), en las que los usuarios se encargan de la creación, lectura, 
actualización y eliminación de los registros, deberían estar normalizadas.Las bases de datos de procesamiento analítico en línea (OLAP) que 
favorecen el análisis y la generación de informes funcionarían mejor con 
un grado de desnormalización, ya que el énfasis está en la velocidad de 
cálculo. Estas incluyen aplicaciones de soporte de decisiones en las que 
los datos se deben analizar rápidamente, pero no deben modificarse.
Tipos de normalización
Primera forma normal (1FN)
• Elimine los grupos repetidos de las tablas individuales.
• Cree una tabla independiente para cada conjunto de datos relacionados.
• Identifique cada conjunto de datos relacionados con una clave principal.
Tipos de normalización
Segunda forma normal (2FN)
• Cree tablas independientes para conjuntos de valores que se apliquen 
a varios registros.
• Relacione estas tablas con una clave externa.
• Se dirá que una relación está en la segunda forma normal, si los 
atributos dato que no forman parte de ninguna clave dependen de 
forma completa de la clave principal(atributo clave) y 
automáticamente será parte de la primera forma normal (1FN).
Tipos de normalización
Tercera forma normal (3FN)
• Tener la 2° forma normal
• Eliminar aquellos campos que no dependan de la clave
• Ninguna columna puede depender de una columna que no tenga una 
clave
• No puede haber datos derivados
Podemos decir que nuestra tabla se encuentra en tercera normal si 
previamente estaba en segunda forma normal y si no existe ninguna 
dependencia funcional transitiva entre los atributos que no son clave.
UML y el modelado de datos
UML es popular entre programadores, pero no suele ser usado por 
desarrolladores de bases de datos. Una razón es sencillamente que los 
creadores de UML no se enfocaron en las bases de datos. A pesar de ello, el 
UML es efectivo para el modelado de alto nivel de datos conceptuales y se 
puede usar en diferentes tipos de diagramas UML.
Diagrama de clases = 1FN
Métricas y la Calidad de Software
Las métricas de calidad de software permiten monitorizar un producto para 
determinar su nivel de calidad aunque, el seguimiento que este tipo de 
medidas permiten llevar a cabo brinda la oportunidad de conocer muchas 
más cosas de una solución
Las métricas de desarrollo de software pueden revelar cómo se está 
desempeñando una aplicación y qué tan efectivo es el equipo de desarrollo 
en su trabajo.
Las organizaciones de TI se basan en una variedad de estos KPI para 
comprender completamente el progreso de los ingenieros de software, al 
igual que la calidad del software, como el rendimiento y la satisfacción del 
usuario
• Productividad del desarrollador
• Rendimiento del software
• Defectos y seguridad
• Experiencia de usuario (UX)
Métricas de productividad del 
desarrollador
Las métricas de productividad permiten a los gerentes de desarrollo ejecutar 
mejor los proyectos.
1. Tiempo de entrega (lead time). El tiempo de entrega es el tiempo que tarda 
algo de principio a fin. En el desarrollo de software, por ejemplo, el tiempo 
de entrega de un proyecto comienza con la propuesta y termina con la 
entrega.
2. Cantidad de código. Los equipos de desarrollo pueden mirar esta métrica de 
software, también llamada miles de líneas de código (KLOC), para 
determinar el tamaño de una aplicación. Si este KPI es alto, podría indicar 
que los desarrolladores fueron productivos en sus esfuerzos de 
programación. Sin embargo, esta métrica no es útil cuando un equipo de 
desarrollo intenta comparar dos proyectos escritos en diferentes lenguajes 
de programación. Además, tenga en cuenta que más código no siempre 
hace que el código sea eficiente o efectivo.
3. Trabajo en curso (WIP). En un contexto de ingeniería de software, WIP es un 
trabajo de desarrollo en el que el equipo ha comenzado a trabajar y que ya 
no está en el backlog. Un equipo puede expresar WIP en un gráfico de 
quemado. Una herramienta común para los sprints ágiles y Scrum, estos 
gráficos muestran cuánto trabajo ha terminado el equipo y la cantidad de 
trabajo que queda por hacer.
4. Velocidad ágil. Para calcular la velocidad, un equipo de desarrollo de 
software ágil analiza los sprints anteriores y cuenta el número de historias de 
usuario o puntos de historia completados a lo largo del tiempo. La velocidad 
ágil es una estimación de qué tan productivo será el equipo en un solo sprint.
5. Tasa de éxito de la meta del sprint. Esta métrica de software calcula el 
porcentaje de elementos que completó el equipo de desarrollo en el backlog 
del sprint. Es posible que un equipo no termine el 100 % del trabajo durante 
un sprint determinado. Sin embargo, el progreso del equipo aún podría 
cumplir con su definición de terminado: el umbral que debe alcanzar un 
proyecto para que una organización lo considere terminado. Si la iteración 
cumple con la definición de hecho, es un éxito.
6. Número de versiones de software. Los equipos ágiles y de DevOps dan 
prioridad a los lanzamientos de software continuos y frecuentes. Con este 
KPI, los equipos pueden realizar un seguimiento de la frecuencia con la que 
lanzan software, ya sea mensual, semanal, diaria, por hora o en cualquier 
otro período de tiempo, y si esa cadencia finalmente ofrece suficiente valor 
comercial.
Métricas de productividad del 
desarrollador
Métricas de rendimiento del 
software
Las métricas de rendimiento miden los atributos no funcionales, es 
decir, cómo se desempeña una aplicación, no lo que realiza.
7. Aspectos del desempeño del software. Las pruebas de rendimiento 
pueden evaluar las siguientes características de una aplicación:
• Escalabilidad
• estabilidad
• capacidad de respuesta
• velocidad
• disponibilidad
• Otras expresiones importantes de métricas de rendimiento del 
software incluyen las siguientes.
8. Rendimiento (throughput). El rendimiento es la cantidad de unidades de 
datos que procesa un sistema en un cierto período de tiempo.
9. Tiempo de respuesta. El tiempo de respuesta mide cuánto tiempo tarda un 
sistema en responder a una consulta o demanda.
10. Fiabilidad, disponibilidad y capacidad de servicio (RAS). RAS se refiere a la 
capacidad del software para cumplir constantemente con sus 
especificaciones; cuánto tiempo funciona en relación con la cantidad 
esperada; y con qué facilidad se puede reparar o mantener.
Métricas de defectos
Los equipos de desarrollo deben comprender cómo fallan las aplicaciones para 
poder construirlas mejor. Estas métricas de desarrollo de software evalúan 
defectos y vulnerabilidades.
11. Densidad de defectos. A nivel de código, los desarrolladores pueden 
tabular el número de defectos por KLOC para evaluar la frecuencia de los 
defectos.
12. Cobertura de código. Esta es la proporción de código fuente que cubren 
las pruebas automatizadas. La métrica del software permite a los 
probadores identificar qué áreas del código aún tienen que probar 
correctamente.
13. Porcentaje de detección de defectos. Esta métrica es una proporción de la 
cantidad de defectos encontrados antes de los lanzamientos de software 
en comparación con el número encontrado después del lanzamiento. Para 
calcular el porcentaje, tome el número de defectos encontrados antes del 
lanzamiento (x) y la cantidad que encontraron los usuarios después del 
lanzamiento (y), y luego calcule x/(x + y). Es preferible un alto porcentaje, 
ya que eso significa que se encontró una mayor proporción de defectos 
antes de que los clientes usaran el software.
Métricas de defectos
14. Deuda técnica. La deuda técnica es una metáfora que refleja el esfuerzo a 
largo plazo, así como los costos temporales y financieros, de los 
desarrolladores que no abordan un problema de desarrollo cuando surge 
por primera vez.
15. Moral como métrica. Trate la felicidad de los empleados o del equipo como 
otro indicador útil de la productividad y el éxito del equipo. Puede que sea 
tan importante como cualquier métrica técnica o KPI de calidad del 
software. Los miembros del equipo estresados ​​o insatisfechos pueden 
erosionar la productividad del trabajoy, en última instancia, el rendimiento 
del software. Mantenga un inventario de números como la rotación de los 
miembros del equipo, también llamada rotación de empleados; un número 
más bajo probablemente significa que los empleados están satisfechos 
dentro de la organización.
16. Vulnerabilidades de seguridad. Los análisis de vulnerabilidades identifican 
las debilidades de seguridad en una aplicación. Cuanto menor sea el número 
de vulnerabilidades encontradas, más seguro será el software.
Las organizaciones de TI utilizan varios promedios para calcular la 
ocurrencia de fallas o defectos de software.
17. Incidentes de seguridad reales. Este KPI cuenta la cantidad de veces 
que un hacker aprovecha una vulnerabilidad en el software. Realice un 
seguimiento de la frecuencia con la que ocurren estas infracciones, la 
gravedad del ataque (por ejemplo, qué datos se robaron) y la cantidad 
de tiempo que duró el incidente.
18.Tiempo medio de detección. El tiempo medio de detección es 
un promedio que indica cuánto tiempo tarda un equipo en notar 
un problema o error.
19.Tiempo medio entre fallos. Esta métrica es un cálculo de qué 
tan común es que un programa falle.
20.Tiempo medio de reparación. El tiempo medio de reparación es 
el promedio que representa la rapidez con que un equipo aborda 
las fallas.
Métricas de defectos
Métricas de usabilidad y UX
Los usuarios experimentan e interactúan con el software de diferentes formas. 
Así como es difícil clasificar las emociones de las personas, también es un 
desafío evaluar su reacción al software. 
21. Métricas de UX. Las mediciones de UX suelen ser cualitativas y pueden 
incluir las respuestas emocionales o corporales de los usuarios, como 
cuánto confían en el software y cómo se mueven sus ojos a través de una 
interfaz de usuario.
22. Métricas de usabilidad. La usabilidad mide qué tan bien el software 
permite a los clientes alcanzar sus objetivos. La usabilidad se puede dividir 
en componentes más pequeños, como los siguientes:
• Facilidad de descubrimiento
• eficiencia
• memorabilidad
• facilidad de aprendizaje
• satisfacción
• accesibilidad, particularmente accesibilidad digital
23. Net Promoter Score (NPS). Esta métrica de software refleja la voluntad de 
los clientes de recomendar una aplicación a otros. Net Promoter Score se 
presenta como un rango de números de 0 a 10. Los clientes con una 
puntuación de 0 a 6 son Detractores; las puntuaciones 7 y 8 son Pasivos; y 
9 y 10 son Promotores.
GRACIAS