Calidad del software

Este artículo necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo agregando citas de fuentes confiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Calidad del software» – noticias  · periódicos  · libros  · académico  · JSTOR ( diciembre de 2021 ) ( Aprenda cómo y cuándo eliminar este mensaje )

En el contexto de la ingeniería de software , la calidad del software se refiere a dos nociones relacionadas pero distintas: ^{[ cita requerida ]}

• La calidad funcional del software refleja qué tan bien cumple o se ajusta a un diseño determinado, en función de los requisitos o especificaciones funcionales . ^[1] Ese atributo también puede describirse como la idoneidad para el propósito de un software o cómo se compara con los competidores en el mercado como un producto que vale la pena . ^[2] Es el grado en que se produjo el software correcto .
• La calidad estructural del software se refiere a cómo cumple con los requisitos no funcionales que respaldan la entrega de los requisitos funcionales, como la solidez o la facilidad de mantenimiento. Tiene mucho más que ver con el grado en que el software funciona según lo necesario .

Muchos aspectos de la calidad estructural pueden evaluarse solo de manera estática a través del análisis de la estructura interna del software, su código fuente (ver Métricas de software ), ^[3] a nivel de unidad y a nivel de sistema (a veces denominado prueba de extremo a extremo ^[4] ), que es en efecto cómo su arquitectura se adhiere a los principios sólidos de la arquitectura de software delineados en un documento sobre el tema por Object Management Group (OMG). ^[5]

Algunas cualidades estructurales, como la usabilidad , pueden evaluarse solo de forma dinámica (los usuarios u otras personas que actúan en su nombre interactúan con el software o, al menos, con algún prototipo o implementación parcial; incluso la interacción con una versión simulada hecha en cardboard representa una prueba dinámica porque dicha versión puede considerarse un prototipo). Otros aspectos, como la confiabilidad, pueden involucrar no solo al software sino también al hardware subyacente, por lo tanto, puede evaluarse tanto de forma estática como dinámica ( prueba de estrés ). ^{[ cita requerida ]}

El uso de pruebas automatizadas y funciones de aptitud puede ayudar a mantener algunos de los atributos relacionados con la calidad. ^[6]

La calidad funcional se suele evaluar de forma dinámica, pero también es posible utilizar pruebas estáticas (como revisiones de software ). ^{[ cita requerida ]}

Históricamente, 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 y la posterior norma ISO/IEC 25000. ^[7] Con base en estos modelos (ver Modelos), el Consorcio para la Calidad del Software de TI (CISQ) ha definido cinco características estructurales deseables principales necesarias para que un software proporcione valor comercial : ^[8] Fiabilidad, Eficiencia, Seguridad, Mantenibilidad y Tamaño (adecuado). ^{[9] [10] [11]}

La medición de la calidad del software cuantifica en qué medida un programa o sistema de software se clasifica en cada una de estas cinco dimensiones. Se puede calcular una medida agregada de la calidad del software mediante un esquema de puntuación cualitativo o cuantitativo o una combinación de ambos y luego un sistema de ponderación que refleje las prioridades. Esta visión de la calidad del software, que se sitúa en un continuo lineal, se complementa con el análisis de los "errores críticos de programación" que, en circunstancias específicas, pueden provocar interrupciones catastróficas o degradaciones del rendimiento que hacen que un sistema determinado no sea adecuado para su uso, independientemente de la calificación basada en mediciones agregadas. Estos errores de programación que se encuentran a nivel de sistema representan hasta el 90 por ciento de los problemas de producción, mientras que a nivel de unidad, aunque sean mucho más numerosos, los errores de programación representan menos del 10 por ciento de los problemas de producción (véase también la regla del noventa por ciento ). En consecuencia, la calidad del código sin el contexto de todo el sistema, como lo describió W. Edwards Deming , tiene un valor limitado. ^{[ cita requerida ]}

Para visualizar, explorar, analizar y comunicar mediciones de calidad de software, los conceptos y técnicas de visualización de información proporcionan medios visuales e interactivos que resultan útiles, en particular, si se deben relacionar varias mediciones de calidad de software entre sí o con componentes de un software o sistema. Por ejemplo, los mapas de software representan un enfoque especializado que "puede expresar y combinar información sobre el desarrollo de software, la calidad de software y la dinámica de sistemas". ^[12]

La calidad del software también juega un papel en la fase de lanzamiento de un proyecto de software. En concreto, la calidad y el establecimiento de los procesos de lanzamiento (también procesos de parches ), ^{[13] [14]} la gestión de la configuración ^[15] son ​​partes importantes de un proceso general de ingeniería de software. ^{[16] [17] [18]}

La calidad del software está motivada por al menos dos perspectivas principales:

• Gestión de riesgos : Los fallos de software han causado más que inconvenientes. Los errores de software pueden causar muertes humanas (véase, por ejemplo: Lista de errores de software ). Las causas han variado desde interfaces de usuario mal diseñadas hasta errores directos de programación , ^{[19] [20] [21]} véase, por ejemplo, el caso del Boeing 737 o los casos de aceleración no intencionada ^{[22] [23]} o los casos del Therac-25 . ^[24] Esto dio lugar a requisitos para el desarrollo de algunos tipos de software, en particular e históricamente para el software integrado en dispositivos médicos y de otro tipo que regulan infraestructuras críticas: "[Los ingenieros que escriben software integrado] ven programas Java que se detienen durante un tercio de segundo para realizar la recolección de basura y actualizar la interfaz de usuario, y visualizan aviones cayendo del cielo". ^[25] En los Estados Unidos, dentro de la Administración Federal de Aviación (FAA), el Servicio de Certificación de Aeronaves de la FAA proporciona programas de software, políticas, orientación y formación, centrándose en el software y el hardware electrónico complejo que tiene un efecto en el producto aéreo (un "producto" es una aeronave, un motor o una hélice). ^[26] Las normas de certificación como DO-178C , ISO 26262 , IEC 62304 , etc. proporcionan orientación.
• Gestión de costes : como en cualquier otro campo de la ingeniería, un producto o servicio de software regido por una buena calidad de software cuesta menos de mantener, es más fácil de entender y puede cambiar de forma más rentable en respuesta a las necesidades empresariales más apremiantes. ^[27] Los datos de la industria demuestran que una mala calidad estructural de las aplicaciones en las aplicaciones empresariales básicas (como la planificación de recursos empresariales (ERP), la gestión de relaciones con los clientes (CRM) o los grandes sistemas de procesamiento de transacciones en los servicios financieros) da como resultado costes, excesos de programación y crea residuos en forma de retrabajo (véase Muda (término japonés) ). ^{[28] [29] [30]} Además, la mala calidad estructural está fuertemente correlacionada con interrupciones empresariales de alto impacto debido a datos corruptos, interrupciones de las aplicaciones, violaciones de seguridad y problemas de rendimiento. ^[31]
  • Los informes del CISQ sobre el costo de la mala calidad estiman un impacto de:
    • 2,08 billones de dólares en 2020 ^{[32] [33]}
    • 2,84 billones de dólares en 2018
  • El Informe sobre el costo de una violación de datos de 2020 de IBM estima que los costos globales promedio de una violación de datos: ^{[34] [35]}
    • 3,86 millones de dólares

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 o de cliente ^{[38] [39]} o incluso de nivel de defectos. ^[40] Las mediciones de 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]

El Software Assurance (SA) cubre tanto la propiedad como el proceso para lograrla: ^[43]

• Confianza [justificable] de que el software está libre de vulnerabilidades, ya sea 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 "Software Extension" del PMBOK del Project Management Institute no define la "calidad del software" en sí, sino la Garantía de Calidad del Software (SQA) como "un proceso continuo que audita otros procesos de software para asegurar que esos procesos se están siguiendo (incluye, por ejemplo, un plan de gestión de calidad del software)", mientras que el Control de Calidad del Software (SCQ) significa "ocuparse de aplicar métodos, herramientas y técnicas para asegurar la satisfacción de los productos de trabajo con respecto a los requisitos de calidad para un software en desarrollo o modificación". ^[44]

La primera definición que la historia de la calidad nos recuerda es la de Shewhart, de 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, hay 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 se ocupa del aspecto metafísico de la calidad. En esta perspectiva, la calidad es “algo por lo que luchamos como ideal, pero que tal vez nunca podamos implementar por completo”. ^[48] Es difícil definirla, pero es similar a lo que un juez federal comentó una vez sobre la obscenidad: “Lo reconozco cuando lo veo”. ^[49]
• La perspectiva del usuario se ocupa de 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 y se basa en las características del producto que satisfacen las necesidades del usuario. ^[48]
• La perspectiva de fabricación considera la calidad como conformidad con los requisitos. Este aspecto de la calidad se destaca en normas como la ISO 9001, que define la calidad como "el grado en el que un conjunto de características inherentes cumple 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 de cualquier producto, fue planteado por el maestro Walter A. Shewhart. La dificultad de definir la calidad es traducir las necesidades futuras del usuario en características mensurables, de modo que se pueda diseñar y fabricar un producto que proporcione satisfacción a un precio que el usuario esté dispuesto a pagar. Esto no es fácil, y tan pronto como uno se siente medianamente exitoso en el empeño, descubre que las necesidades del consumidor han cambiado, han entrado competidores, etc. ^[51]

—W  . Edwards Deming

La calidad es una decisión del cliente, no de un ingeniero, ni de un departamento de marketing, ni de una dirección general. Se basa en la experiencia real del cliente con el producto o servicio, medida en relación con sus requisitos –expresados ​​o no, conscientes o meramente intuidos, técnicamente operativos o totalmente subjetivos– y siempre representa un objetivo en movimiento en un mercado competitivo. ^[52]

La palabra calidad tiene múltiples significados. Dos de ellos predominan en el uso de la palabra: 1. La calidad consiste en las características del producto que satisfacen las necesidades de los clientes y, por lo tanto, proporcionan satisfacción con el producto. 2. La calidad consiste en la ausencia de deficiencias. Sin embargo, en un manual como éste es conveniente estandarizar una definición breve de la palabra calidad como "aptitud para el uso". ^[53]

Tom DeMarco ha propuesto que "la calidad de un producto es una función de cuánto cambia el mundo para mejor". ^{[ cita requerida ]} Esto puede interpretarse en el sentido de 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 a la hora de definir la calidad es que "todos sienten que la entienden" ^[56] y otras definiciones de calidad del software podrían basarse en la ampliación de las diversas descripciones del concepto de calidad utilizado en los negocios.

La calidad del software también suele confundirse con la garantía de calidad o la gestión de resolución de problemas ^[57] o el control de calidad ^[58] o DevOps . Se superpone con las áreas mencionadas anteriormente (consulte también las definiciones de PMI), pero se distingue porque no se centra únicamente en las pruebas, sino también en los procesos, la gestión, las mejoras, las evaluaciones, etc. ^[58]

Aunque los conceptos presentados en esta sección son aplicables tanto a la calidad estructural como a la funcional del software, la medición de esta última se realiza esencialmente a través de pruebas de software . ^[59] Las pruebas no son suficientes: según un estudio, "los programadores individuales tienen una eficiencia inferior al 50% a la hora de encontrar errores en su propio software. Y la mayoría de las formas de prueba tienen una eficiencia de sólo el 35%. Esto dificulta determinar la calidad [del software]". ^[60]

La medición de la calidad del software consiste en cuantificar en qué medida un sistema o software posee características deseables. Esto se puede realizar a través de medios cualitativos o cuantitativos o una combinación de ambos. En ambos casos, para cada característica deseable, existe un conjunto de atributos mensurables cuya existencia en un software o sistema tiende a estar correlacionada y asociada con esa característica. Por ejemplo, un atributo asociado con la portabilidad es la cantidad de declaraciones dependientes del objetivo en un programa. Más precisamente, utilizando el enfoque de implementación de la función de calidad , estos atributos mensurables son los "cómo" que se deben aplicar para permitir los "qué" en la definición de calidad del software anterior.

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 posterior modelo de calidad ISO/IEC 25000:2005. El enfoque principal se centra en la calidad estructural interna. Se han creado subcategorías para gestionar áreas específicas como la arquitectura de aplicaciones empresariales y características técnicas como el acceso y la manipulación de datos o la noción 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 los errores de programación y los defectos de producción revelan que los errores básicos de código representan el 92 por ciento de los errores totales en el código fuente. Estos numerosos problemas a nivel de código representan, en última instancia, 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 de los defectos totales, pero consumen más de la mitad del esfuerzo dedicado a solucionar los problemas y conducen al 90 por ciento de los problemas graves de confiabilidad, seguridad y eficiencia en producción. ^{[61] [62]}

Muchas de las medidas de software existentes cuentan elementos estructurales de la aplicación que resultan del análisis del código fuente en busca de instrucciones individuales ^[63], tokens ^[64], estructuras de control ( Complejidad ) y objetos. ^[65]

La medición de la calidad del software consiste en cuantificar hasta qué punto un sistema o software se clasifica en función de estas dimensiones. El análisis se puede realizar utilizando un enfoque cualitativo o 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 que se miden].

Esta visión de la calidad del software en un continuo lineal tiene que complementarse con la identificación de errores críticos de programación discretos. Estas vulnerabilidades pueden no fallar en un caso de prueba, pero son el resultado de malas prácticas que, en circunstancias específicas, pueden provocar interrupciones catastróficas, degradaciones del rendimiento, violaciones de seguridad, datos corruptos y una miríada de otros problemas ^[66] que hacen que un sistema determinado sea de facto inadecuado para su uso, independientemente de su calificación basada en mediciones agregadas. Un ejemplo bien conocido de vulnerabilidad es la Enumeración de debilidades comunes ^[67] , un repositorio de vulnerabilidades en el código fuente que exponen las aplicaciones a violaciones de seguridad.

La medición de las características críticas de la aplicación implica la medición de 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 anterior. 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 si se pretende que sea un predictor valioso de los resultados de calidad que afectan al negocio. El enfoque en capas para calcular las medidas de las características que se muestra en la figura anterior fue propuesto por primera vez por Boehm y sus colegas en TRW (Boehm, 1978) ^[68] y es el enfoque adoptado en las normas de las series ISO 9126 y 25000. Estos atributos se pueden medir 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 a través del 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 es distinto del análisis de código básico, local y a nivel de componentes que suelen realizar las herramientas de desarrollo , que se ocupan principalmente de consideraciones de implementación y son cruciales durante las actividades de depuración y prueba .

Las causas fundamentales de la baja confiabilidad se encuentran en una combinación de incumplimiento de las buenas prácticas de arquitectura y codificación. Este incumplimiento se puede detectar midiendo los atributos de calidad estáticos de una aplicación. La evaluación de los atributos estáticos subyacentes a la confiabilidad de una aplicación proporciona una estimación del nivel de riesgo comercial y la probabilidad de posibles fallas y defectos que la aplicación experimentará cuando se ponga en funcionamiento.

Para evaluar la confiabilidad es necesario comprobar al menos las siguientes prácticas recomendadas de ingeniería de software y atributos técnicos:

Dependiendo de la arquitectura de la aplicación y los componentes de terceros utilizados (como bibliotecas o marcos externos), se deben definir controles personalizados siguiendo las líneas trazadas en la lista anterior de mejores prácticas para garantizar una mejor evaluación de la confiabilidad del software entregado.

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

Para evaluar la eficiencia del rendimiento es necesario comprobar al menos las siguientes prácticas recomendadas y atributos técnicos de ingeniería de software:

• 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 ^[69] ( Mejores prácticas de codificación )

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

Para evaluar la seguridad es necesario comprobar al menos las siguientes prácticas recomendadas de ingeniería de software y atributos técnicos:

• Implementación, gestión de un proceso de desarrollo consciente y reforzado de la seguridad, por ejemplo, Security Development Lifecycle (Microsoft) o Secure Engineering Framework de IBM. ^[74]
• Prácticas de arquitectura de aplicaciones seguras ^{[75] [76]}
• Cumplimiento de diseño multicapa
• Mejores prácticas de seguridad (validación de entrada, inyección SQL, secuencias de comandos entre sitios, control de acceso, etc.) ^{[77] [78]}
• Prácticas de programación seguras y buenas ^[69]
• Manejo de errores y excepciones

La mantenibilidad incluye conceptos de modularidad, comprensibilidad, modificabilidad, capacidad de prueba, reutilización y transferibilidad de un equipo de desarrollo a otro. Estos no toman la forma de problemas críticos a nivel de código. Más bien, la mala mantenibilidad es típicamente el resultado de miles de infracciones menores con las mejores prácticas en documentación, estrategia para evitar la complejidad y prácticas básicas de programación que marcan la diferencia entre código limpio y fácil de leer y código desorganizado y difícil de leer. ^[79]

Para evaluar la mantenibilidad es necesario comprobar las siguientes prácticas recomendadas 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 se pueden clasificar como imprudentes vs. prudentes y deliberadas vs. inadvertidas, ^{[80] [81]} 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, el código fuente mantenible . ^[82]

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. Básicamente, existen dos tipos de tamaños de software que se deben medir: el tamaño técnico (huella) y el tamaño funcional:

• Existen varios métodos de dimensionamiento técnico de software que se han descrito ampliamente. 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 que generan errores.
• El método más común para medir el tamaño funcional es el análisis de puntos de función . El análisis de puntos de función mide el tamaño del software entregable desde la perspectiva de un usuario. El dimensionamiento de los puntos de función se realiza en función de los requisitos del usuario y proporciona una representación precisa tanto del tamaño para el desarrollador/calculador como del valor (funcionalidad a entregar) y refleja la funcionalidad empresarial que se entrega 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 está entonces disponible para su uso junto con numerosas medidas para cuantificar y evaluar la entrega y el rendimiento del software (costo 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 del análisis de puntos de función cuenta con el apoyo del Grupo Internacional de Usuarios de Puntos de Función ( IFPUG ). Se puede aplicar en las primeras etapas del ciclo de vida del desarrollo de software y no depende de líneas de código como el método Backfiring, que es un tanto impreciso. El método es independiente de la tecnología y se puede utilizar para realizar análisis comparativos entre organizaciones y sectores.

Desde el inicio 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 de dimensionamiento como COSMIC, NESMA, puntos de caso de uso, FP Lite, FP rápidos y tempranos y, más recientemente, Story Points. El punto de función tiene un historial de precisión estadística y se ha utilizado como una unidad común de medición del trabajo en numerosos proyectos de gestión de desarrollo de aplicaciones (ADM) o de subcontratación, y actúa 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 y, por lo tanto, puede requerir mucha mano de obra y ser costoso en iniciativas de gran escala, como el desarrollo de aplicaciones o los contratos de subcontratación. Este aspecto negativo de la aplicación de la metodología puede ser lo que motivó a los líderes de TI de la industria a formar el Consorcio para la Calidad del Software de TI, centrado en la introducción de 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 certificaciones de contadores de puntos de función.

CISQ define el dimensionamiento como una 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. ^[83]

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

Estos suelen estar relacionados con la tecnología y dependen en gran medida del contexto, los objetivos comerciales y los riesgos. Algunos pueden considerar que es fundamental respetar las convenciones de nomenclatura, mientras que otros (por ejemplo, quienes preparan el terreno para una transferencia de conocimientos) lo considerarán absolutamente fundamental.

Los errores críticos de programación también se pueden clasificar según las características de CISQ. A continuación se muestra un ejemplo básico:

• Fiabilidad
  • Evite patrones de software que conduzcan a un comportamiento inesperado ( variable no inicializada , punteros nulos, etc.)
  • Los métodos, procedimientos y funciones que realizan operaciones de inserción, actualización, eliminación, creación de tabla o selección deben incluir la gestión de errores.
  • Las funciones multiproceso deben ser seguras para subprocesos, por ejemplo, los servlets o las clases de acción de struts no deben tener campos estáticos de instancia o 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 utilizan un índice en tablas grandes en un bucle
• Seguridad
  • Evite campos en 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 la validación de entrada para evitar fallas de secuencias de comandos entre sitios o fallas de inyección SQL
• Mantenibilidad
  • Se deben evitar los árboles de herencia profundos y la anidación para mejorar la comprensión.
  • Los módulos deben estar acoplados de forma flexible (fanout, intermediarios) para evitar la propagación de modificaciones.
  • Aplicar convenciones de nombres homogéneas

Las propuestas más recientes de modelos de calidad, como las de Squale y Quamoco ^[85], promueven una integración directa de la definición de atributos de calidad y su medición. Al desglosar los atributos de calidad o incluso definir capas adicionales, los atributos de calidad complejos y abstractos (como la confiabilidad o la capacidad de mantenimiento) se vuelven más manejables y medibles. Esos modelos de calidad se han aplicado en contextos industriales, pero no han recibido una adopción generalizada.

• Pautas de calidad del sistema operativo Android que incluyen listas de verificación para la interfaz de usuario, la seguridad, etc. Julio de 2021
• Asociación de Gestores Marítimos de Tecnologías de la Información y las Comunicaciones (AMMITEC). Directrices de calidad del software marítimo. Septiembre de 2017
• Capers Jones y Olivier Bonsignour, "La economía de la calidad del software", Addison-Wesley Professional, 1.ª edición, 31 de diciembre de 2011, ISBN  978-0-13-258220-9
• CAT Lab - Laboratorio de herramientas de análisis de código del CNES (en GitHub)
• Girish Suryanarayana, Proceso de software versus calidad de diseño: ¿un tira y afloja? ^[86]
• Ho-Won Jung, Seung-Gweon Kim y Chang-Sin Chung. Medición de la calidad de los productos de software: un estudio de la norma ISO/IEC 9126. IEEE Software , 21(5):10–13, septiembre/octubre de 2004.
• Organización Internacional de Normalización. Ingeniería de software: calidad del producto. Parte 1: Modelo de calidad . ISO, Ginebra, Suiza, 2001. ISO/IEC 9126-1:2001(E).
• Medición de la calidad de los productos de software: la serie ISO 25000 y CMMI (sitio SEI)
• MSQF: un marco de calidad del software basado en mediciones Biblioteca de la Universidad de Cornell
• Omar Alshathry, Helge Janicke, "Optimización del aseguramiento de la calidad del software", compsacw, págs. 87–92, Talleres de la 34.ª Conferencia Anual sobre Aplicaciones y Software Informático del IEEE, 2010.
• Robert L. Glass. Software de calidad de la construcción . Prentice Hall, Upper Saddle River, Nueva Jersey, 1992.
• Roland Petrasch, "La definición de 'calidad del software': un enfoque práctico", ISSRE, 1999
• Profesional de calidad de software, ^[87] Sociedad Estadounidense para la Calidad (ASQ)
• Revista de calidad de software ^[88] de Springer Nature
• Spinellis, Diomidis (4 de abril de 2006). Calidad del código: la perspectiva del código abierto. Upper Saddle River, Nueva Jersey, EE. UU.: Addison-Wesley Professional. ISBN 978-0-321-16607-4.
• Stephen H. Kan. Métricas y modelos en ingeniería de calidad de software . Addison-Wesley, Boston, MA, segunda edición, 2002.
• Stefan Wagner. Control de calidad de productos de software. Springer, 2013.

Notas

Bibliografía

Wikimedia Commons tiene medios relacionados con Calidad del software .

• Cuando el código es el rey: cómo dominar la excelencia en el software automotriz (McKinsey, 2021)
• Calidad del software de sistemas integrados: ¿por qué es tan a menudo terrible? ¿Qué podemos hacer al respecto? (por Philip Koopman)
• Estándares de calidad de código de CISQ ™
• Blog del CISQ: https://blog.it-cisq.org
• Guía para el aseguramiento de la calidad del software (ESA)
• Guía para la aplicación de los estándares de ingeniería de software de la ESA a pequeños proyectos de software (ESA)
• Descripción general de los servicios de garantía de productos de software de la ESA (NASA/ESA)
• Nuestro enfoque de calidad en Volkswagen Software Dev Center Lisboa
• Guías de estilo de Google
• Garantizar la calidad de los productos en Google (2011)
• Garantía de software de la NASA
• Grupo de calidad de software del NIST
• Puntos de función automatizados OMG/CISQ (ISO/IEC 19515)
• Estándar de deuda técnica automatizada OMG
• Garantía de calidad automatizada (artículo publicado en IREB por Harry Sneed)
• Pruebas estructuradas: una metodología de pruebas que utiliza la métrica de complejidad ciclomática (1996)
• Análisis de la calidad de las aplicaciones mediante herramientas de análisis de código (Microsoft, Documentación, Visual Studio, 2016)