Cuando hablamos de calidad del software hacemos referencia al grupo de propiedades que contiene un determinado programa informático, y cómo influyen sus características en su utilidad y en la respuesta que los usuarios esperan de él.
Es importante, para entender el concepto de calidad de software, determinar qué entendemos por calidad.
Pues, podemos decir que un producto tiene calidad cuando a través de sus cualidades cumple las condiciones necesarias para su efectivo uso, alcanzando o superando las expectativas de quien lo adquiere.
Índice de temas
¿Qué es la calidad del software?
La calidad del software es el conjunto de atributos que hacen a un programa informático y a la facilidad de interactuar con un dispositivo electrónico a través de él realizando determinadas tareas.
Dicha calidad, al igual que su utilidad, depende del desarrollo del software. Siempre que se inicia un proyecto de desarrollo de software, el objetivo es que sus fallas sean cercanas a cero.
Sin embargo, debemos entender que muchas veces el concepto de calidad es ambiguo y subjetivo.
Pues un producto puede cumplir todas las necesidades de un determinado cliente pero a su vez puede no contar con la seguridad suficiente para proteger un sistema informático.
Veremos a continuación qué criterios de evaluación se utilizan para medir la calidad del software y describiremos los distintos puntos de vista desde los que se los analiza.
¿Qué criterios se usan para medir y evaluar la calidad del software? ¿Cómo se hace?
Luego de haber explicado el concepto de calidad del software, cabe preguntarse si la misma se puede medir. Pues la respuesta es que sí.
De hecho, existen determinados criterios de evaluación. Lo primero que debemos saber es que no todos los programas de software deben ser medidos de la misma forma. Esto se debe a que no todos necesitan la misma justeza a la hora de evitar los errores y las fallas.
Para ejemplificar, sabemos que un software cuya tarea es la de controlar naves espaciales necesita que sus errores sean nulos y es con esa vara que se medirá su calidad.
Ahora bien, a la hora de medir la calidad del software podemos centrarnos en dos enfoques. Por un lado, podemos evaluar su funcionalidad. Esto quiere decir que debemos determinar si el programa puede realizar con eficacia las tareas para las que fue creado.
Por otro lado, la otra manera de evaluar un software determinado es mediante el análisis de su estructura. Esto simplemente se refiere a sus características que no hacen a su funcionalidad.
Aquí lo que importa es el rendimiento del programa, si su mantenimiento es posible y en caso de que lo sea si es sencillo y por último su capacidad de adaptación o escalabilidad.
Certificaciones, normativa ISO 9000
Por lo general, las empresas que comercializan productos u ofrecen servicios tratan de conseguir certificaciones dadas por la normativa ISO que pongan a prueba la calidad de sus procesos de producción.
Las normas ISO no son normas específicas para cada ámbito de la producción o los servicios, sino que son normas generales, por lo cual es necesario hacer una adaptación acorde al tipo de bien cuya calidad se está examinando.
Esto es importante para el software debido a que uno de los aspectos que determinan su calidad es su correspondencia con la definición ISO de calidad, la cual es ampliamente aceptada, y su adecuamiento a las reglas del grupo ISO 9000.
Llevar adelante un proceso de certificación ISO para determinar la calidad del software es costoso pero necesario. De todas formas, debemos tener en cuenta que en el caso de los programas informáticos, lo que se certifica es la metodología para llevar a cabo su desarrollo.
Un auditor se acerca al lugar de desarrollo del software y realiza un control de los procesos internos. Si estos cumplen con las normas ISO, emite un certificado para la empresa y para el proceso de desarrollo del programa.
Cómo estar seguro de la calidad del software
- Prestar más atención al tipo de tecnología y a la aplicación utilizada;
- adherirse a prácticas de codificación seguras adoptando un enfoque de seguridad por diseño;
- centrarse en la madurez e integración de las metodologías de desarrollo;
- vigilar constantemente las violaciones de las normas que puedan poner en peligro la calidad del código fuente;
- convertir las prácticas de mejora de la calidad del código en procesos metódicos y sistemáticamente repetidos.
Estos son, en definitiva, los puntos estratégicos que hay que vigilar, según se desprende de una amplia encuesta destinada a conocer las tendencias globales actuales de la calidad estructural del software y las aplicaciones informáticas desarrolladas en todo el mundo. Cabe señalar que el término “calidad estructural” se utiliza en el estudio para referirse principalmente a la solidez de la ingeniería arquitectónica y la “salud” de la codificación de una aplicación, más que a la corrección con la que se implementan los requisitos funcionales solicitados por el usuario.
Los cinco factores de la calidad del software
Partamos de una detallada investigación llevada a cabo por Cast en 2017, y que en su esencia resumida aquí sigue siendo válida en la actualidad, (Cast Research on Application Software Health): el informe trata de hacer un balance del nivel de salud del software empresarial y de cuál es su valor desde el punto de vista del negocio, midiendo su calidad estructural en base a unos benchmarks y puntos de referencia o, si se prefiere, de cinco “factores de salud” o características fundamentales de la calidad estructural, que se identifican con la robustez, la seguridad, la eficiencia del rendimiento, la transferibilidad, la modificabilidad.
En esencia, la calidad estructural se mide identificando las violaciones de las normas que representan las buenas prácticas arquitectónicas y de desarrollo de códigos en cada una de estas cinco áreas clave. Por lo tanto, definámoslos mejor.
- El factor de robustez mide la probabilidad de que se produzcan interrupciones, la dificultad de recuperación y la posibilidad de que los datos se corrompan, ligada a las malas prácticas de codificación.
- El factor de seguridad, por su parte, mide las violaciones de las metodologías de encriptación seguras que abren el camino al acceso no autorizado, a las interacciones engañosas, al robo de datos o a la violación de la confidencialidad.
- La eficiencia es el factor de salud que mide la probabilidad de una posible degradación del rendimiento, y el uso ineficiente de los recursos (procesadores, memoria, redes), de nuevo causado por metodologías de desarrollo de código deficientes.
- El factor de modificabilidad mide la dificultad de modificar las aplicaciones, añadir funcionalidad, corregir errores o cambiar el entorno de la aplicación.
- Por último, la transferibilidad es el factor que mide la dificultad de llevar a cabo el trabajo o la dificultad de entender la aplicación y ser productivo al trabajar con ella.
Las puntuaciones de estos cinco factores de salud se calculan en una escala de 1 (bajo/medio) a 4 (alto/bueno), a partir de la cual se analiza la aplicación para identificar las violaciones de más de 1.200 normas de buenas prácticas arquitectónicas y de codificación.
Tipos de métricas
Para poder evaluar la calidad del software podemos utilizar ciertas métricas que además nos ayudan a controlar el proceso de desarrollo y a introducir nuevas herramientas y soluciones.
Para esto, hay determinados tipos de métricas que no podemos dejar de tener en cuenta si queremos llevar adelante una correcta evaluación.
En primer lugar, tenemos las métricas de exactitud que se relacionan de forma directa con la estructura del software y con su precisión. En este caso son importantes la etapa de despliegue, así como también el mantenimiento del programa.
Por otro lado, es de vital importancia considerar las métricas de usabilidad y rendimiento. En cuanto a la usabilidad podemos decir que es necesario que el software sea sencillo de usar para el usuario. Si constituye una complejidad, la calidad del software se ve afectada.
Cuando hablamos de la métrica de rendimiento, se evalúa cómo se desempeña el software en cada uno de sus módulos.
Pero además, es necesario que el programa sea veloz, que tenga baja latencia y una capacidad de respuesta aceptable. Pues todo eso se evalúa con las métricas de eficiencia que contribuyen, en gran medida, a la calidad del software.
Mejora del software: principales recomendaciones
Antes de explicar la muestra, cómo se llevó a cabo la investigación y algunos aspectos concretos del estudio, conviene destacar de una vez las valiosas recomendaciones para los equipos de desarrollo que se desprenden de los resultados resumidos del informe Cast.
- Para obtener información precisa y útil sobre el rendimiento comparable, las actividades de evaluación comparativa de software deben realizarse dentro de la categoría tecnológica y el tipo de aplicación específicos. De hecho, los resultados de la evaluación comparativa realizada únicamente con respecto al tipo de industria pueden ser engañosos, debido a los efectos de otros factores más influyentes que pueden variar dentro de las organizaciones.
- Debería prestarse más atención a las prácticas de codificación segura, ya que muchas aplicaciones obtuvieron una puntuación inaceptablemente baja en este ámbito. De hecho, las puntuaciones de la categoría “seguridad” mostraron mayores variaciones que las de cualquier otro factor de salud.
- La tercera recomendación es que, para mejorar las puntuaciones en los factores de salud, las organizaciones deben mejorar la madurez de sus procesos y metodologías de desarrollo. Las organizaciones con poca madurez obtuvieron sistemáticamente una puntuación más baja en los factores de salud.
- Es aconsejable adoptar metodologías híbridas para el desarrollo de aplicaciones “críticas para el negocio”, ya que los métodos híbridos obtuvieron una mayor puntuación en los factores de salud que las metodologías “ágiles” y “en cascada”, integrando la planificación del análisis arquitectónico con una rápida retroalimentación sobre la calidad.
- Es preferible evitar la creación de equipos de más de 20 desarrolladores; los equipos de menos de diez miembros parecen ser óptimos.
- Al considerar estrategias como la externalización o la deslocalización, hay que prestar atención a los factores que han demostrado influir en la calidad estructural, como la madurez de la organización, la metodología de desarrollo o el tamaño del equipo, ya que estos factores influyen más que otros, como la fuente (interna, externalizada) o el lugar de desarrollo (deslocalizado, onshore).
- Es importante analizar periódicamente el código fuente antes de liberarlo, para identificar las violaciones de las normas de calidad que pongan en riesgo las operaciones o los costes. Las infracciones a nivel de sistema son las más críticas, ya que son mucho más costosas de resolver, y pueden requerir varios ciclos de liberación antes de ser eliminadas por completo.
- Es necesario concebir la mejora de la calidad estructural como un proceso iterativo, que debe proseguirse a través de numerosas versiones del software para alcanzar umbrales de calidad óptimos.
Dos niveles de normas de calidad
Un aspecto esencial de la evaluación de la calidad estructural del código es dividir las reglas de calidad en dos niveles de análisis: reglas a nivel de código y reglas a nivel de sistema. Las primeras, aclara Cast, son normas evaluadas a nivel de la unidad de código (por ejemplo, dentro de una clase, un método, una subrutina, un módulo) y las infracciones en este ámbito suelen implicar problemas de “higiene” de la codificación y simples defectos.
Las reglas a nivel de sistema, en cambio, son reglas arquitectónicas cuya evaluación implica a múltiples componentes, a menudo distribuidos en diferentes niveles de la aplicación. Las infracciones en este ámbito son difíciles o imposibles de detectar a través de las actividades normales de prueba, pero suelen ser las culpables de las interrupciones, los agujeros de seguridad, la corrupción de datos y las dificultades para soportar o ampliar la aplicación (escalado).
Los datos utilizados como muestra para el análisis del informe Crash proceden de Appmarq, el repositorio digital de Cast, que la empresa describe como la mayor base de datos sobre sistemas informáticos reales, que contiene datos recogidos durante los análisis estructurales a nivel de sistema de grandes aplicaciones informáticas. El repositorio incluye 1.850 solicitudes presentadas por 329 organizaciones para su posterior análisis. En conjunto, estas aplicaciones sumaron 1,03 Blocs (mil millones de líneas de código). Las organizaciones que participan en la investigación se encuentran principalmente en Europa continental (Francia, Bélgica, Italia, Alemania y España), el Reino Unido, América del Norte (Estados Unidos y Canadá) e India. Desde el punto de vista tecnológico, la muestra incluye aplicaciones escritas principalmente en Cobol, Java-EE, .NET, Oracle Server y otras tecnologías, como PHP, C/C++, PowerBuilder, C# y Visual Basic.
En cuanto al tamaño de las aplicaciones, el umbral mínimo para aceptarlas en la muestra era de 10 Kloc (kilo o mil líneas de código), que se elevaba a aplicaciones que contenían más de un Mloc (millón de líneas de código).
En cuanto al desarrollo de código, las tecnologías más utilizadas en la muestra de Crash son Java-EE (40%) y Cobol (22%).
Desde el punto de vista de los segmentos industriales, la muestra incluye solicitudes de 329 empresas de doce sectores: servicios financieros, seguros, telecomunicaciones, fabricación, consultoría informática, energía, servicios públicos, administración pública, comercio minorista, proveedores de software, productos farmacéuticos y medios de comunicación.
Por último, a nivel de tipos de aplicaciones, los tipos de sistemas más frecuentes en la muestra son los sistemas de transacciones básicas y los sistemas de planificación de recursos empresariales (ERP).
Para qué sirve medir la calidad: factores que influyen en la calidad del producto final
A la hora de hablar de la importancia de la calidad del software, debemos tener en cuenta por qué es importante que el producto final cumpla con sus tareas de forma segura.
Un programa con fallas no detectadas puede ocasionar problemas futuros tales como grandes pérdidas de dinero sufridas por la empresa que lo contrató.
En alguna medida, es para evitar estas consecuencias no deseadas que existe un proceso de evaluación de la calidad del software. Este último, como sabemos, contribuye a una etapa de diseño más efectiva pero también ayuda a lograr una mejor etapa de análisis y diseño.
Al evaluar la calidad del software además es posible encontrar las fallas y errores que tiene la aplicación. El hecho de conocerlos a través de una correcta metodología hace que sea sencillo luego trabajar sobre las correcciones necesarias.
Calidad estructural
Se comprobó que el tamaño de una aplicación tiene poco o ningún efecto en su calidad estructural. Por otro lado, la calidad estructural difiere significativamente cuando se comparan las tecnologías de desarrollo, siendo Cobol y Oracle Server las que generalmente obtienen las puntuaciones más bajas y JEE (Java-EE) las más altas.
Sin embargo, el efecto de la tecnología sobre la calidad estructural es más fuerte que el del sector industrial al que pertenece la aplicación. Además, la tecnología utilizada en el desarrollo del sistema de aplicación puede ser más importante que el tipo de sistema en sí (sistema transaccional principal, ERP, sitio web, portal, CRM, aplicación analítica) a la hora de determinar su puntuación en el factor de salud.
Herramientas que se utilizan
Con el objetivo de evaluar la calidad del software existen diversas herramientas que nos pueden ayudar a completar esta tarea.
Se trata de herramientas que permiten llevar a cabo actividades de prueba ya sea en la planificación, en el registro de defectos, en la fase de testeo o en cualquier parte del proceso de desarrollo.
Elegir la mejor herramienta de calidad del software dependerá siempre de la tarea específica que queramos realizar.
Algunas de las más comunes y efectivas son PDM, Check Style, Google CodePro Analytix, SOAPUI, Selenium y Simian.
La madurez organizacional es crucial
Ser capaz de pasar de una organización “indisciplinada” a una empresa innovadora y madura en sus procesos de desarrollo marca la diferencia a la hora de conseguir una calidad estructural en el software. Un grado de madurez cuya evolución Cast mide mediante el modelo CMMI (Capability Maturity Model Integration), que se divide en tres niveles.
En el nivel 1 (riesgo sin controlar) se encuentran las organizaciones en las que una mala planificación y disciplina crean plazos insostenibles para los proyectos, lo que lleva a los desarrolladores a producir un exceso de defectos en el software, con poco tiempo para identificarlos.
Luego, en el nivel 2 (riesgo limitado) se encuentran las organizaciones en las que los proyectos se llevan a cabo utilizando sus propias metodologías, pero en las que los compromisos del proyecto y las líneas de base se gestionan para garantizar que los desarrolladores tengan tiempo para realizar un trabajo de calidad.
En el nivel 3 (riesgo controlado) se encuentran las organizaciones en las que los proyectos utilizan normas y procesos organizativos creados mediante metodologías en las que los desarrolladores confían para ofrecer sistemas de alta calidad.
Por tanto, no es de extrañar que las aplicaciones desarrolladas en organizaciones de nivel 1 de CMMI, en las que se cometen muchos errores sin tiempo suficiente para corregirlos, obtuvieran una puntuación más baja que las creadas en organizaciones de nivel 2, en las que las actividades de desarrollo son más disciplinadas y la calidad estructural del software mejora, o de nivel 3, en las que se aplican las mejores prácticas, implementando las capacidades de nivel 2 e integrándolas en los procesos organizativos estándar.
Figura 4 – Método de desarrollo híbrido: el mejor camino hacia la calidad – fuente: Informe de Choque de Cast 2017
Metodología de desarrollo “híbrida”: la opción ganadora
Hablando de prácticas de codificación, las puntuaciones más altas en cuanto a la calidad estructural del software las obtuvieron las metodologías de desarrollo híbridas: de hecho, las diferencias en los factores de salud entre los métodos de desarrollo “ágil” y “en cascada” fueron mínimas, y ambos obtuvieron puntuaciones más bajas que los métodos híbridos, que resultan de la combinación de la planificación y el diseño de la arquitectura de la aplicación, con una rápida retroalimentación sobre los defectos, retroalimentación que se reitera a lo largo del ciclo de diseño. Esto permite a los desarrolladores abordar antes los problemas de calidad del sistema y la arquitectura, e identificar con mayor precisión los defectos, incluso mientras desarrollan el código.
7 tipos de pruebas funcionales para mejorar la calidad del software
En un proceso de desarrollo es elemental realizar pruebas de software. Para que estas sean efectivas y contribuyan a la calidad del software, debe existir una comunicación fluida entre desarrolladores, analistas y evaluadores.
En este apartado nos centraremos de forma particular en las pruebas funcionales las cuales de ser bien ejecutadas pueden ahorrarnos mucho tiempo en el proceso de desarrollo.
Entre los distintos tipos de pruebas funcionales encontramos, por ejemplo, a las pruebas unitarias y a las de componentes. Por su lado, las pruebas unitarias testean que las células del código que se haya desarrollado en un componente determinado cumplan con la función esperada.
Luego, las pruebas de componentes van más allá y verifican la funcionalidad del componente en sí mismo.
Algunos ejemplos de este tipo de pruebas son las pruebas de UI, las pruebas de carga que aseguran el rendimiento, pruebas de login con credenciales válidas e inválidas y también la inyección de SQL a través de determinados componentes de UI con el objetivo de verificar la seguridad.
Dentro de las pruebas funcionales que hacen a la calidad del software, una de las más importantes es la prueba de humo. Si la misma sale bien es probable que estemos luego ante una compilación estable. Es por esto que suele ser una de las primeras que se lleva adelante.
El núcleo de estas pruebas es la verificación de las funcionalidades que hacen a la importancia del programa. En otras palabras, se trata de verificar que el software pueda llevar adelante sus tareas de forma realmente efectiva.
Otra prueba funcional que comúnmente es utilizada es la de integración. El objetivo de estas es evaluar a los componentes individuales. De esa manera se podrá verificar cómo funcionarán los módulos cuando estén integrados.
A la hora de llevar a cabo el desarrollo de un software, comúnmente se suele introducir muchos cambios que tienen por objetivo agregar o mejorar funciones.
De modo que es necesario realizar pruebas de regresión para determinar que dichos cambios no alteren ninguna de las funcionalidades que tiene la aplicación que se está desarrollando.
Pero si las modificaciones no fueron tan significativas, es más efectivo realizar pruebas de cordura. Estas últimas no solo verifican si el problema fue solucionado sino que también aseguran que no se haya cambiado ninguna configuración a raíz de los cambios.
Por último, dentro de la fase de testing, tenemos a las pruebas de aceptación del usuario. Se trata de usuarios reales de la aplicación tomando contacto con ella y verificando que cumpla y satisfaga todos los requisitos.
Básicamente, lo que se hace es llevar la aplicación a la realidad para ver cómo es su desempeño.
Tests unitarios, de integración y funcionales
Tal como habíamos anticipado, con el objetivo de evaluar la calidad del software existen diferentes tipos de tests. En este apartado describiremos los unitarios, de integración y funcionales.
Las pruebas funcionales, tal como su nombre lo indica, garantizan que las características y funciones del software respondan acorde a lo planeado. Se trata de tests que ponen a prueba la usabilidad del programa a desarrollar.
En la misma línea, encontramos a las pruebas unitarias y las de integración. Mientras que las de integración prueban diferentes módulos que trabajan de forma individual de una aplicación como grupo, las unitarias se centran en probar piezas individuales del software.
Las primeras pruebas que se suelen realizar en el proceso de desarrollo de software son las unitarias.
¿Cómo se conecta un programa de control de calidad al proceso de desarrollo?
El proceso de desarrollo de software puede ser muy largo y complejo, y muchas veces es necesario introducir modificaciones para poder agregar nuevas funciones. Es por eso que es necesario llevar a cabo un control de calidad constante para que se pueda conseguir el mejor producto final posible.
Para conectar un programa de control de calidad al proceso de desarrollo es importante que se sigan tres pasos.
En primer lugar, las pruebas de control de calidad deben constituir una prioridad en las etapas de planificación.
Por otro lado, las listas de verificación son muy importantes, así como también la creación de planes de prueba de control de calidad. Lo mejor es tener estos últimos con anticipación.
Por último, es importante poder informar y encontrar los problemas para solucionarlos de la forma más rápida y efectiva posible. Generalmente se configura una canalización para informar y realizar un seguimiento de los problemas.
¿Por qué hacer un testeo previo?
El proceso de testeo previo en la etapa de desarrollo de software es de suma importancia para obtener un software de calidad.
Es necesario comprender que el testeo del proyecto a desarrollar debe ser realizado en todas las etapas del proceso de creación. Sin los testeos previos no podremos identificar desvíos en las configuraciones de las funcionalidades o cualquier otro error que pueda surgir.
Pero además de facilitar la posibilidad de detectar errores, el testing es necesario para comprobar si la aplicación cumple los requerimientos del cliente.
Lo cierto es que si existe algún error, lo más conveniente es que se detecte antes de lanzar el producto para que pueda ser corregido, porque una vez que esté en el mercado será demasiado tarde.
Problemas que pueden surgir
En muchas ocasiones, los testeos y las pruebas de funcionalidad son dejadas de lado o hechas de forma incorrecta. En los casos en los que se ignora la importancia de verificar la calidad del software, los productos desarrollados suelen generar inconvenientes en el futuro.
Un software de mala calidad puede hacer que la empresa pierda mucho dinero. En primer lugar, los clientes disminuyen su confianza en los desarrollos de la compañía lo que lógicamente producirá una disminución en las ventas.
La reputación es esencial para una empresa de software y para mantenerse vigente en el mercado.
Pero además, si el software tiene errores, volver a empezar el proceso de desarrollo para resolverlos será sin duda más costoso que el ahorro producido por no evaluar la calidad como correspondía en un principio.
La inteligencia del software: una prioridad para los CIO
Otro informe de referencia es el Software Intelligence Report – CIO Priorities in the Digital Age, publicado este año por Cast, en el que se encuestó a 500 líderes de TI (incluidos 150 directores de informática, 125 arquitectos de software y 125 desarrolladores de aplicaciones, en organizaciones medianas y grandes) sobre sus objetivos tecnológicos y su capacidad para alcanzarlos en función de la Inteligencia de Software a la que pueden recurrir, en comparación con sus carteras de software existentes.
Entre las principales conclusiones del estudio se encuentra no sólo que los CIOs carecen de la visibilidad adecuada sobre el diseño del software para tomar decisiones acertadas sobre los activos informáticos de la empresa, sino también que los departamentos de sistemas de información son incapaces de prevenir los riesgos operativos, corrigiendo los fallos estructurales demasiado tarde para que no se produzca una ralentización del proceso de digitalización.
Un aspecto interesante de la encuesta es que no hay escasez de capacidades tecnológicas; cuando la empresa requiere soluciones que implican incluso habilidades tecnológicas avanzadas, los equipos de TI son capaces de desarrollarlas. Lo que falta, sin embargo, es un análisis claro y coherente que sea capaz de explorar por completo los sistemas de software que son fundamentales para las operaciones empresariales.
En particular, se identifican dos retos principales: por un lado, la prevalencia de los sistemas heredados que aún soportan operaciones empresariales clave dentro de la organización; por otro, la existencia de datos incoherentes sobre las actividades de diseño y mantenimiento de software.
Calidad del software
Los CIOs carecen de mucha información a la hora de tomar decisiones estratégicas sobre la arquitectura del software – Fuente: oftware Intelligence Report, Cast
Calidad del software e ISO 9126, esto es lo que dice
La ISO (Organización Internacional de Normalización), en colaboración con la IEC (Comisión Electrotécnica Internacional), responsables de describir un modelo de calidad del software, colaboraron en la redacción de las normas y directrices ISO/IEC 9126.
Surgió un modelo que sugiere un enfoque de la calidad que los vendedores pueden adoptar para mejorar sus procesos y, en consecuencia, la calidad del software que producen.
Los aspectos técnicos cubiertos por la norma se refieren, además del modelo de calidad del software clasificado por 6 características (funcionalidad, fiabilidad, eficiencia, usabilidad, mantenibilidad y portabilidad), a las métricas de calidad externa (que miden el comportamiento del código sobre la base de pruebas, observación de la ejecución, etc.); las métricas de calidad interna (que se aplican al software no ejecutable, por ejemplo, el código fuente, durante las fases de diseño y codificación); las métricas de calidad de uso, es decir, el punto de vista del usuario del software.
Artículo publicado originalmente en 07 Ene 2022
