Calidad del software

La calidad del software es la "capacidad de un producto de software para cumplir con los requisitos". ^{[ 36 ] [ 37 ]} mientras que para otros puede ser sinónimo de creación de valor para el cliente ^{[ 38 ] [ 39 ]} o incluso nivel de defectos. ^{[ 40 ]} Las mediciones de la calidad del software se pueden dividir en tres partes: calidad del proceso, calidad del producto que incluye propiedades internas y externas y, por último, calidad en uso, que es el efecto del software. ^{[ 41 ]}

ASQ utiliza la siguiente definición: La calidad del software describe los atributos deseables de los productos de software. Existen dos enfoques principales: la gestión de defectos y los atributos de calidad. ^{[ 42 ]}

La garantía de software (SA) abarca tanto la propiedad como el proceso para lograrla: ^{[ 43 ]}

• Confianza justificada en que el software está libre de vulnerabilidades, ya sean diseñadas intencionalmente en el software o insertadas accidentalmente en cualquier momento durante su ciclo de vida, y que el software funciona de la manera prevista.
• El conjunto planificado y sistemático de actividades que garantizan que los procesos y productos del ciclo de vida del software se ajusten a los requisitos, estándares y procedimientos.

La Guía PMBOK del Project Management Institute, en su sección "Extensión de Software", define no la "calidad del software" en sí misma, sino el Aseguramiento de la Calidad del Software (ACS) como "un proceso continuo que audita otros procesos de software para garantizar que se sigan (incluye, por ejemplo, un plan de gestión de la calidad del software)". Por otro lado, el Control de Calidad del Software (CCS) significa "cuidar la aplicación de métodos, herramientas y técnicas para garantizar que los productos de trabajo cumplan con los requisitos de calidad de un software en desarrollo o modificación". ^{[ 44 ]}

La primera definición de calidad registrada en la historia proviene de Shewhart a principios del siglo XX: «Hay dos aspectos comunes de la calidad: uno de ellos tiene que ver con la consideración de la calidad de una cosa como una realidad objetiva independiente de la existencia del hombre. El otro tiene que ver con lo que pensamos, sentimos o percibimos como resultado de la realidad objetiva. En otras palabras, existe un lado subjetivo de la calidad». ^{[ 45 ]}

Kitchenham y Pfleeger, informando además sobre las enseñanzas de David Garvin, identifican cinco perspectivas diferentes sobre la calidad: ^{[ 46 ] [ 47 ]}

• La perspectiva trascendental aborda el aspecto metafísico de la calidad. Desde esta perspectiva, la calidad es «algo hacia lo que aspiramos como ideal, pero que quizás nunca logremos implementar por completo». ^{[ 48 ]} Es difícil definirla, pero se asemeja a lo que un juez federal comentó una vez sobre la obscenidad: «La reconozco cuando la veo». ^{[ 49 ]}
• La perspectiva del usuario se centra en la idoneidad del producto para un contexto de uso determinado. Mientras que la visión trascendental es etérea, la visión del usuario es más concreta, basada en las características del producto que satisfacen las necesidades del usuario. ^{[ 48 ]}
• La perspectiva de fabricación representa la calidad como conformidad con los requisitos. Este aspecto de la calidad se destaca en estándares como ISO 9001, que define la calidad como "el grado en que un conjunto de características inherentes cumple con los requisitos" (ISO/IEC 9001 ^{[ 50 ]} ).
• La perspectiva del producto implica que la calidad puede apreciarse midiendo las características inherentes del producto.
• La perspectiva final de la calidad se basa en el valor. ^{[ 38 ]} Esta perspectiva reconoce que las diferentes perspectivas de la calidad pueden tener diferente importancia o valor para las distintas partes interesadas.

El problema inherente a los intentos de definir la calidad de un producto, casi cualquier producto, fue planteado por el maestro Walter A. Shewhart. La dificultad para definir la calidad radica en traducir las necesidades futuras del usuario en características medibles, de modo que se pueda diseñar y fabricar un producto que brinde satisfacción a un precio que el usuario esté dispuesto a pagar. Esto no es fácil, y tan pronto como uno se siente relativamente exitoso en el empeño, descubre que las necesidades del consumidor han cambiado, han surgido competidores, etc. ^{[ 51 ]}

La calidad es una determinación del cliente, no del ingeniero, ni del departamento de marketing, ni de la dirección general. Se basa en la experiencia real del cliente con el producto o servicio, medida en función de sus requisitos —explícitos o implícitos, conscientes o meramente intuidos, técnicamente operativos o totalmente subjetivos— y siempre representa un objetivo cambiante en un mercado competitivo. ^{[ 52 ]}

La palabra calidad tiene múltiples significados. Dos de ellos predominan en su uso: 1. La calidad consiste en aquellas características del producto que satisfacen las necesidades de los clientes y, por lo tanto, les brindan satisfacción. 2. La calidad consiste en la ausencia de deficiencias. Sin embargo, en un manual como este, resulta conveniente estandarizar una definición breve de la palabra calidad como "idoneidad para el uso". ^{[ 53 ]}

Tom DeMarco propuso que "la calidad de un producto depende de cuánto contribuye a mejorar el mundo". DeMarco, Tom (1999). "La gestión puede hacer que la calidad sea (im)posible". Cutter IT Summit.{{cite web}}: Faltante o vacío |url=( ayuda ) Esto puede interpretarse como que la calidad funcional y la satisfacción del usuario son más importantes que la calidad estructural a la hora de determinar la calidad del software.

Otra definición, acuñada por Gerald Weinberg en Quality Software Management: Systems Thinking, es "La calidad es valor para alguna persona". ^{[ 54 ] [ 55 ]}

Uno de los desafíos al definir la calidad es que "todos sienten que la entienden" ^{[ 56 ]} y otras definiciones de calidad del software podrían basarse en extender las diversas descripciones del concepto de calidad utilizadas en los negocios.

La calidad del software también suele confundirse con el aseguramiento de la calidad o la gestión de la resolución de problemas ^{[ 57 ]} o el control de calidad ^{[ 58 ]} o DevOps . Si bien se superpone con estas áreas (véanse también las definiciones del PMI), es distintiva, ya que no se centra únicamente en las pruebas, sino también en los procesos, la gestión, las mejoras, las evaluaciones, etc. ^{[ 58 ].}

La calidad del software es difícil de medir de una manera que pueda aplicarse prácticamente a la toma de decisiones de los desarrolladores. Esta dificultad surge en parte porque muchos atributos de calidad, como la complejidad o la mantenibilidad, son multidimensionales y no pueden ser capturados completamente por una sola métrica. ^{[ 59 ]}

La medición de la calidad del software consiste en cuantificar hasta qué punto un sistema o software posee características deseables. Esto puede realizarse mediante métodos cualitativos, cuantitativos o una combinación de ambos. En ambos casos, para cada característica deseable, existe un conjunto de atributos medibles cuya presencia en un software o sistema tiende a estar correlacionada y asociada con dicha característica. Por ejemplo, un atributo asociado con la portabilidad es el número de instrucciones dependientes del destino en un programa. Más precisamente, utilizando el enfoque de Despliegue de la Función de Calidad , estos atributos medibles son los "cómos" que deben aplicarse para posibilitar los "qués" de la definición de Calidad del Software mencionada anteriormente.

La estructura, clasificación y terminología de los atributos y métricas aplicables a la gestión de la calidad del software se han derivado o extraído de la norma ISO 9126-3 y del modelo de calidad ISO/IEC 25000:2005. El enfoque principal se centra en la calidad estructural interna. Se han creado subcategorías para abordar áreas específicas, como la arquitectura de las aplicaciones empresariales y características técnicas como el acceso y la manipulación de datos o el concepto de transacciones.

El árbol de dependencia entre las características de calidad del software y sus atributos medibles se representa en el diagrama de la derecha, donde cada una de las 5 características que importan para el usuario (derecha) o propietario del sistema empresarial depende de atributos medibles (izquierda):

• Prácticas de arquitectura de aplicaciones
• Prácticas de codificación
• Complejidad de la aplicación
• Documentación
• Portabilidad
• Volumen técnico y funcional

Las correlaciones entre errores de programación y defectos de producción revelan que los errores básicos de código representan el 92 por ciento del total de errores en el código fuente. Estos numerosos problemas a nivel de código finalmente representan solo el 10 por ciento de los defectos en producción. Las malas prácticas de ingeniería de software a nivel de arquitectura representan solo el 8 por ciento del total de defectos, pero consumen más de la mitad del esfuerzo dedicado a corregir problemas y dan lugar al 90 por ciento de los graves problemas de fiabilidad, seguridad y eficiencia en producción. ^{[ 62 ] [ 63 ]}

Muchas de las medidas de software existentes cuentan los elementos estructurales de la aplicación que resultan del análisis del código fuente para tales instrucciones individuales ^{[ 64 ]} tokens ^{[ 65 ]} estructuras de control ( Complejidad ) y objetos. ^{[ 66 ]}

La medición de la calidad del software consiste en cuantificar en qué medida un sistema o software cumple con estas dimensiones. El análisis puede realizarse mediante un enfoque cualitativo, cuantitativo o una combinación de ambos para proporcionar una visión global [utilizando, por ejemplo, promedios ponderados que reflejen la importancia relativa entre los factores medidos].

Esta visión de la calidad del software en un continuo lineal debe complementarse con la identificación de errores de programación críticos discretos . Estas vulnerabilidades pueden no provocar fallos en un caso de prueba, pero son el resultado de malas prácticas que, en determinadas circunstancias, pueden provocar interrupciones catastróficas, degradación del rendimiento, brechas de seguridad, datos corruptos y un sinfín de otros problemas ^{[ 67 ]} que hacen que un sistema determinado sea de facto inadecuado para su uso, independientemente de su calificación basada en mediciones agregadas. Un ejemplo conocido de vulnerabilidad es la Enumeración de Debilidades Comunes ^{[ 68 ]} , un repositorio de vulnerabilidades en el código fuente que exponen las aplicaciones a brechas de seguridad.

La medición de las características críticas de la aplicación implica medir los atributos estructurales de la arquitectura, la codificación y la documentación en línea de la aplicación, como se muestra en la imagen superior. Por lo tanto, cada característica se ve afectada por atributos en numerosos niveles de abstracción en la aplicación, y todos los cuales deben incluirse en el cálculo de la medida de la característica para que sea un predictor valioso de los resultados de calidad que afectan al negocio. El enfoque por capas para calcular las medidas de las características que se muestra en la figura superior fue propuesto por primera vez por Boehm y sus colegas en TRW (Boehm, 1978) ^{[ 69 ]} y es el enfoque adoptado en las normas ISO 9126 y 25000. Estos atributos pueden medirse a partir de los resultados analizados de un análisis estático del código fuente de la aplicación. Incluso las características dinámicas de las aplicaciones, como la fiabilidad y la eficiencia del rendimiento, tienen sus raíces causales en la estructura estática de la aplicación.

El análisis y la medición de la calidad estructural se realizan mediante el análisis del código fuente , la arquitectura , el marco de software y el esquema de la base de datos , en relación con los principios y estándares que, en conjunto, definen la arquitectura conceptual y lógica de un sistema. Esto se diferencia del análisis básico, local y a nivel de componentes que suelen realizar las herramientas de desarrollo , las cuales se centran principalmente en aspectos de implementación y son cruciales durante las actividades de depuración y prueba .

Las causas fundamentales de la baja fiabilidad radican en una combinación de incumplimiento de las buenas prácticas de arquitectura y codificación. Este incumplimiento puede detectarse midiendo los atributos de calidad estáticos de una aplicación. Evaluar los atributos estáticos que determinan la fiabilidad de una aplicación permite estimar el nivel de riesgo empresarial y la probabilidad de fallos y defectos que la aplicación pueda experimentar una vez puesta en funcionamiento.

Para evaluar la fiabilidad es necesario comprobar, como mínimo, las siguientes buenas prácticas de ingeniería de software y atributos técnicos:

En función de la arquitectura de la aplicación y de los componentes de terceros utilizados (como bibliotecas o marcos de trabajo externos), se deben definir comprobaciones personalizadas siguiendo las pautas establecidas en la lista de mejores prácticas anterior para garantizar una mejor evaluación de la fiabilidad del software entregado.

Al igual que con la fiabilidad, las causas de la ineficiencia en el rendimiento suelen residir en el incumplimiento de las buenas prácticas de arquitectura y codificación, las cuales pueden detectarse midiendo los atributos de calidad estática de una aplicación. Estos atributos estáticos predicen posibles cuellos de botella en el rendimiento operativo y futuros problemas de escalabilidad, especialmente en aplicaciones que requieren una alta velocidad de ejecución para gestionar algoritmos complejos o grandes volúmenes de datos.

Para evaluar la eficiencia del rendimiento es necesario comprobar, como mínimo, las siguientes mejores prácticas de ingeniería de software y atributos técnicos:

• Prácticas de arquitectura de aplicaciones
• Interacciones apropiadas con recursos costosos y/o remotos
• Rendimiento del acceso a los datos y gestión de datos
• Gestión de memoria, red y espacio en disco
• Cumplimiento de las prácticas de codificación ^{[ 70 ]} ( Mejores prácticas de codificación )

La calidad del software incluye la seguridad del software . ^{[ 71 ]} Muchas vulnerabilidades de seguridad resultan de prácticas deficientes de codificación y arquitectura, como la inyección SQL o el cross-site scripting. ^{[ 72 ] [ 73 ]} Estas están bien documentadas en listas mantenidas por CWE, ^{[ 74 ]} y el SEI/Computer Emergency Center (CERT) de la Universidad Carnegie Mellon. ^{[ 70 ]}

Para evaluar la seguridad es necesario comprobar, como mínimo, las siguientes buenas prácticas de ingeniería de software y atributos técnicos:

• Implementación y gestión de un proceso de desarrollo que tenga en cuenta la seguridad y que mejore su resistencia, por ejemplo, el Ciclo de vida de desarrollo seguro (Microsoft) o el Marco de ingeniería segura de IBM. ^{[ 75 ]}
• Prácticas de arquitectura de aplicaciones seguras ^{[ 76 ] [ 77 ]}
• Cumplimiento del diseño multicapa
• Mejores prácticas de seguridad (validación de entrada, inyección SQL, secuencias de comandos entre sitios, control de acceso, etc.) ^{[ 78 ] [ 79 ]}
• Prácticas de programación seguras y buenas ^{[ 70 ]}
• Manejo de errores y excepciones

La mantenibilidad incluye conceptos como modularidad , comprensibilidad, modificabilidad, capacidad de prueba, reutilización y transferibilidad entre equipos de desarrollo. Estos no se manifiestan como problemas críticos a nivel de código. Más bien, una mala mantenibilidad suele ser el resultado de miles de infracciones menores a las buenas prácticas de documentación, estrategias para evitar la complejidad y prácticas básicas de programación que marcan la diferencia entre un código limpio y fácil de leer y un código desorganizado y difícil de leer. ^{[ 80 ]}

Para evaluar la mantenibilidad es necesario comprobar las siguientes buenas prácticas de ingeniería de software y atributos técnicos:

La mantenibilidad está estrechamente relacionada con el concepto de deuda técnica de Ward Cunningham , que es una expresión de los costos resultantes de la falta de mantenibilidad. Las razones por las que la mantenibilidad es baja pueden clasificarse como imprudentes frente a prudentes y deliberadas frente a inadvertidas, ^{[ 81 ] [ 82 ]} y a menudo tienen su origen en la incapacidad de los desarrolladores, la falta de tiempo y objetivos, su descuido y las discrepancias en el costo de creación y los beneficios de la documentación y, en particular, del código fuente mantenible . ^{[ 83 ]}

Para medir el tamaño del software, es necesario recopilar correctamente todo el código fuente, incluidos los scripts de estructura de la base de datos, el código fuente de manipulación de datos, los encabezados de los componentes, los archivos de configuración, etc. Existen esencialmente dos tipos de tamaños de software que se pueden medir: el tamaño técnico (huella) y el tamaño funcional.

• Existen varios métodos de dimensionamiento técnico de software que han sido ampliamente descritos. El método de dimensionamiento técnico más común es el número de líneas de código (#LOC) por tecnología, número de archivos, funciones, clases, tablas, etc., a partir de los cuales se pueden calcular los puntos de función de retroceso;
• El método más común para medir el tamaño funcional es el análisis de puntos de función . Este análisis mide el tamaño del software desde la perspectiva del usuario. El dimensionamiento de puntos de función se basa en los requisitos del usuario y proporciona una representación precisa tanto del tamaño para el desarrollador/estimador como del valor (funcionalidad a entregar), reflejando la funcionalidad empresarial que se ofrece al cliente. El método incluye la identificación y ponderación de las entradas, salidas y almacenes de datos reconocibles por el usuario. El valor del tamaño resultante se puede utilizar junto con diversas métricas para cuantificar y evaluar la entrega y el rendimiento del software (coste de desarrollo por punto de función; defectos entregados por punto de función; puntos de función por mes de personal).

El estándar de dimensionamiento de análisis de puntos de función cuenta con el respaldo del Grupo Internacional de Usuarios de Puntos de Función ( IFPUG ). Puede aplicarse en las primeras etapas del ciclo de vida del desarrollo de software y, a diferencia del método Backfiring, que resulta algo impreciso, no depende de las líneas de código. Este método es independiente de la tecnología y puede utilizarse para análisis comparativos entre organizaciones e industrias.

Desde la creación del Análisis de Puntos de Función, han surgido diversas variantes y la familia de técnicas de dimensionamiento funcional se ha ampliado para incluir medidas como COSMIC, NESMA, Puntos de Casos de Uso, FP Lite, FP Tempranos y Rápidos, y más recientemente, Puntos de Historia. El Análisis de Puntos de Función cuenta con un historial de precisión estadística y se ha utilizado como una unidad de medida común en numerosos proyectos de gestión del desarrollo de aplicaciones (ADM) o subcontratación, sirviendo como la "moneda" con la que se prestan los servicios y se mide el rendimiento.

Una limitación común de la metodología de Puntos de Función es que se trata de un proceso manual, lo que puede resultar laborioso y costoso en iniciativas a gran escala, como el desarrollo de aplicaciones o la subcontratación. Este aspecto negativo de la metodología podría ser lo que motivó a los líderes de TI del sector a formar el Consorcio para la Calidad del Software de TI, centrado en introducir un estándar de métricas computables para automatizar la medición del tamaño del software, mientras que el IFPUG sigue promoviendo un enfoque manual, ya que la mayor parte de su actividad se basa en las certificaciones de contadores de puntos de función.

CISQ define el dimensionamiento como la estimación del tamaño del software para respaldar la estimación de costos, el seguimiento del progreso u otras actividades relacionadas con la gestión de proyectos de software. Se utilizan dos estándares: Puntos de Función Automatizados para medir el tamaño funcional del software y Puntos de Mejora Automatizados para medir el tamaño del código funcional y no funcional en una sola medida. ^{[ 84 ]}

Los errores críticos de programación son malas prácticas específicas de arquitectura y/o codificación que resultan en el mayor riesgo de interrupción del negocio, ya sea inmediato o a largo plazo. ^{[ 85 ]}

Estas prácticas suelen estar relacionadas con la tecnología y dependen en gran medida del contexto, los objetivos comerciales y los riesgos. Algunos consideran importante respetar las convenciones de nomenclatura, mientras que otros, como quienes preparan el terreno para una transferencia de conocimiento, lo consideran fundamental.

Los errores críticos de programación también pueden clasificarse según las características de CISQ. Ejemplo básico a continuación:

• Fiabilidad
  • Evite patrones de software que puedan provocar comportamientos inesperados ( variables no inicializadas , punteros nulos, etc.).
  • Los métodos, procedimientos y funciones que realizan Inserciones, Actualizaciones, Eliminaciones, Creaciones de Tablas o Selecciones deben incluir gestión de errores.
  • Las funciones multihilo deben ser seguras para subprocesos; por ejemplo, las clases de acción de servlets o Struts no deben tener campos estáticos de instancia/no finales.
• Eficiencia
  • Garantizar la centralización de las solicitudes de los clientes (entrantes y de datos) para reducir el tráfico de la red.
  • Evite las consultas SQL que no utilicen un índice contra tablas grandes en un bucle.
• Seguridad
  • Evite campos en las clases de servlet que no sean estáticos finales.
  • Evite el acceso a los datos sin incluir la gestión de errores.
  • Verifique los códigos de retorno de control e implemente mecanismos de manejo de errores.
  • Asegúrese de validar las entradas para evitar vulnerabilidades de secuencias de comandos entre sitios o inyecciones SQL.
• Mantenibilidad
  • Se deben evitar los árboles de herencia profundos y el anidamiento para mejorar la comprensibilidad.
  • Los módulos deben estar débilmente acoplados (distribución, intermediarios) para evitar la propagación de modificaciones.
  • Imponer convenciones de nomenclatura homogéneas

Las propuestas más recientes para modelos de calidad, como Squale y Quamoco ^{[ 86 ],} promueven la integración directa de la definición y la medición de los atributos de calidad. Al desglosar los atributos de calidad o incluso definir capas adicionales, los atributos complejos y abstractos (como la fiabilidad o la mantenibilidad) se vuelven más manejables y medibles. Estos modelos de calidad se han aplicado en contextos industriales, pero no han tenido una adopción generalizada.