Calidad del software

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 dado, según los requisitos o especificaciones funcionales. ^[1] Ese atributo también puede describirse como la idoneidad para el propósito de una pieza de software o cómo se compara con la competencia en el mercado como un producto que vale la pena . ^[2] Es el grado en el 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 capacidad de mantenimiento. Tiene mucho más que ver con el grado en que el software funciona según sea ​​necesario .

Muchos aspectos de la calidad estructural solo pueden evaluarse estáticamente mediante el análisis de la estructura interna del software, su código fuente (ver Métricas del software ), ^[3] a nivel de unidad, 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 descritos en un documento sobre el tema por Object Management Group (OMG). ^[5]

Sin embargo algunas cualidades estructurales, tales como la facilidad de uso , pueden ser evaluados solamente dinámicamente (usuarios u otras personas que actúan en su interactúan nombre con el software o, al menos, algunos prototipo o aplicación parcial; incluso la interacción con una versión maqueta realizada en cartón representa una dinámica prueba 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, se puede evaluar tanto estática como dinámicamente ( prueba de estrés ). ^{[ cita requerida ]}

La calidad funcional se evalúa normalmente 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 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 . ^[6] Sobre la base de 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 una pieza de software proporcione valor comercial : ^[7] Fiabilidad, Eficiencia, Seguridad, Mantenibilidad y (adecuado) Tamaño. ^{[8] [9] [10]}

La medición de la calidad del software cuantifica hasta qué punto un programa de software o sistema califica a lo largo de cada una de estas cinco dimensiones. Se puede calcular una medida agregada de la calidad del software a través de 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 coloca en un continuo lineal se complementa con el análisis de "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 clasificación basada en mediciones agregadas. Estos errores de programación que se encuentran a nivel del sistema representan hasta el 90 por ciento de los problemas de producción, mientras que a nivel de unidad, incluso si son mucho más numerosos, los errores de programación representan menos del 10 por ciento de los problemas de producción (ver también la regla del noventa y noventa ). Como 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 ver, explorar, analizar y comunicar las medidas de calidad del software, los conceptos y las técnicas de visualización de información proporcionan medios visuales e interactivos útiles, en particular, si varias medidas de calidad del software tienen que estar relacionadas 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 del software y la dinámica del sistema". ^[11]

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

Motivación

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

• Gestión de riesgos : la falla del software ha causado más que inconvenientes. Los errores de software pueden causar muertes humanas (consulte, por ejemplo: Lista de errores de software ). Las causas van desde interfaces de usuario mal diseñadas hasta errores directos de programación , ^{[18] [19] [20]} ver por ejemplo el caso del Boeing 737 o los casos de aceleración no intencionada ^{[21] [22]} o los casos Therac-25 . ^[23] Esto resultó en requisitos para el desarrollo de algunos tipos de software, particularmente e históricamente para software integrado en dispositivos médicos y otros que regulan las infraestructuras críticas: "[Los ingenieros que escriben software integrado] ven que los programas Java se estancan durante un tercio de segundo para realizar la recolección de basura y actualizar la interfaz de usuario, y visualizan aviones cayendo del cielo ". ^[24] 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 capacitación, se enfoca en software y hardware electrónico complejo que tiene un efecto en el producto aerotransportado (a " producto "es un avión, un motor o una hélice). ^{[25] 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 gobernado 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 necesidades empresariales urgentes. ^[26] Los datos de la industria demuestran que la mala calidad estructural de las aplicaciones en las principales aplicaciones comerciales (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) genera costos, sobrecostos y genera desperdicio la forma de retrabajo (ver Muda (término japonés) ). ^{[27] [28] [29]} Además, la mala calidad estructural está fuertemente correlacionada con interrupciones comerciales de alto impacto debido a datos corruptos, interrupciones de aplicaciones, brechas de seguridad y problemas de rendimiento. ^[30]
  • CISQ informa sobre el costo de la mala calidad estima un impacto de:
    • 2,08 billones de dólares en 2020 ^{[31] [32]}
    • $ 2,84 billones en 2018
  • El informe de IBM sobre el costo de una violación de datos de 2020 estima que los costos globales promedio de una violación de datos: ^{[33] [34]}
    • $ 3,86 millones

Definiciones

YO ASI

La calidad del software es la "capacidad de un producto de software para cumplir con los requisitos". ^{[35] [36]} mientras que para otros puede ser sinónimo de creación de valor o de cliente ^{[37] [38]} o incluso nivel de defecto. ^[39]

ASQ

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

NIST

Software Assurance (SA) cubre tanto la propiedad como el proceso para lograrlo: ^[41]

• Confianza [justificable] de que el software está libre de vulnerabilidades, ya sea diseñado intencionalmente en el software o insertado accidentalmente en cualquier momento durante su ciclo de vida y que el software funciona de la manera prevista.
• El conjunto de actividades planificadas y sistemáticas que garantizan que los procesos y productos del ciclo de vida del software se ajusten a los requisitos, estándares y procedimientos.

PMI

La Guía del PMBOK del Project Management Institute , "Extensión de software", no define la "calidad del software" en sí misma, sino la garantía de calidad del software (SQA) como "un proceso continuo que audita otros procesos de software para asegurarse de que esos procesos se están siguiendo (incluye, por ejemplo, un plan de gestión de la calidad del software) ". mientras que el Control de Calidad del Software (SCQ) significa "cuidar de aplicar métodos, herramientas, técnicas para asegurar la satisfacción de los productos de trabajo hacia los requisitos de calidad para un software en desarrollo o modificación". ^[42]

Otros generales e históricos

La primera definición de calidad que recuerda la historia es 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 de el hombre. El otro tiene que ver con lo que pensamos, sentimos o sentimos como resultado de la realidad objetiva. En otras palabras, hay un lado subjetivo de la calidad ". ^[43]

Kitchenham y Pfleeger, que informan además sobre las enseñanzas de David Garvin, identifican cinco perspectivas diferentes sobre la calidad: ^{[44] [45]}

• La perspectiva trascendental se ocupa del aspecto metafísico de la calidad. En esta visión de la calidad, es "algo por lo que nos esforzamos como un ideal, pero es posible que nunca lo implementemos por completo". ^[46] Difícilmente se puede definir, pero es similar a lo que un juez federal comentó una vez sobre la obscenidad: "Lo sé cuando lo veo". ^[47]
• La perspectiva del usuario se preocupa por la idoneidad del producto para un contexto de uso dado. 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. ^[46]
• La perspectiva de fabricación representa 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 que un conjunto de características inherentes cumple los requisitos" (ISO / IEC 9001 ^[48] ).
• La perspectiva del producto implica que la calidad se puede apreciar midiendo las características inherentes del producto.
• La perspectiva final de la calidad se basa en valores. ^[37] Esta perspectiva reconoce que las diferentes perspectivas de la calidad pueden tener diferente importancia o valor para los distintos interesados.

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 es traducir las necesidades futuras del usuario en características mensurables, de modo que un producto pueda diseñarse y producirse para dar satisfacción a un precio que pagará el usuario. Esto no es fácil, y tan pronto como uno se siente bastante exitoso en el esfuerzo, descubre que las necesidades del consumidor han cambiado, los competidores han entrado, etc. ^[49]

-  W. Edwards Deming

La calidad es una determinación del cliente, no una determinación de un ingeniero, no una determinación de marketing ni una determinación de la gerencia general. Se basa en la experiencia real del cliente con el producto o servicio, comparándolo con sus requisitos, expresados ​​o no, conscientes o simplemente percibidos, técnicamente operativos o completamente subjetivos, y siempre representando un objetivo en movimiento en un mercado competitivo. ^[50]

La palabra calidad tiene múltiples significados. Dos de estos significados dominan el uso de la palabra: 1. Calidad consiste en aquellas características del producto que satisfacen las necesidades de los clientes y, por lo tanto, brindan satisfacción al producto. 2. La calidad consiste en estar libre de deficiencias. Sin embargo, en un manual como este es conveniente estandarizar una definición corta de la palabra calidad como "aptitud para el uso". ^[51]

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 para determinar la calidad del software.

Otra definición, acuñada por Gerald Weinberg en Quality Software Management: Systems Thinking, es "La calidad es un valor para alguna persona". ^{[52] [53]} Esta definición enfatiza que la calidad es inherentemente subjetiva: diferentes personas experimentarán la calidad del mismo software de manera diferente. Una fortaleza de esta definición son las preguntas que invita a los equipos de software a considerar, como "¿Quiénes son las personas que queremos que valoren nuestro software?" y "¿Qué será de valor para ellos?".

Otros significados y controversias

Uno de los desafíos a la hora de definir la calidad es que "todos sienten que la entienden" ^[54] y otras definiciones de la calidad del software podrían basarse en la ampliación de las diversas descripciones del concepto de calidad que se utilizan en los negocios.

La calidad del software también se confunde a menudo con la garantía de calidad o la gestión de resolución de problemas ^[55] o el control de calidad ^[56] o DevOps . Se superpone con las áreas antes mencionadas (véanse también las definiciones de PMI), pero es distintivo, ya que no se centra únicamente en las pruebas, sino también en los procesos, la gestión, las mejoras, las evaluaciones, etc. ^[56]

Medición

Aunque los conceptos presentados en esta sección son aplicables tanto a la calidad del software estructural como funcional, la medición de este último se realiza esencialmente a través de pruebas [ver artículo principal: Pruebas de software ]. ^[57] Sin embargo, las pruebas no son suficientes: según un estudio, los programadores individuales son menos del 50% eficientes para encontrar errores en su propio software. Y la mayoría de las formas de prueba solo tienen una eficiencia del 35%. Esto dificulta la determinación de la calidad [del software]. ^[58]

Introducción

Relación entre las características deseables del software (derecha) y los atributos medibles (izquierda).

La medición de la calidad del software consiste en cuantificar hasta qué punto 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 medibles cuya existencia en una pieza de software o sistema tiende a correlacionarse y asociarse con esta característica. Por ejemplo, un atributo asociado con la portabilidad es el número 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 medibles son los "cómo" que deben aplicarse para habilitar 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 el posterior modelo de calidad ISO / IEC 25000: 2005. El foco principal está en la calidad estructural interna. Se han creado subcategorías para manejar áreas específicas como la arquitectura de aplicaciones comerciales y características técnicas como el acceso y 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 al 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 de código básico representan el 92 por ciento del total de errores en el código fuente. Estos numerosos problemas a nivel de código eventualmente representan solo el 10 por ciento de los defectos en la producción. Las malas prácticas de ingeniería de software en los niveles de arquitectura representan solo el 8 por ciento del total de defectos, pero consumen más de la mitad del esfuerzo dedicado a solucionar problemas y conducen al 90 por ciento de los problemas serios de confiabilidad, seguridad y eficiencia en la producción. ^{[59] [60]}

Análisis basado en código

Muchas de las medidas de software existentes cuentan los elementos estructurales de la aplicación que resultan de analizar el código fuente para tales instrucciones individuales ^[61] tokens ^[62] estructuras de control ( complejidad ) y objetos. ^[63]

La medición de la calidad del software consiste en cuantificar hasta qué punto un sistema o software califica en 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 agregada [utilizando, por ejemplo, promedios ponderados que reflejan la importancia relativa entre los factores que se están midiendo].

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 . Es posible que estas vulnerabilidades no fallen 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, infracciones de seguridad, datos corruptos y una miríada de otros problemas ^[64] 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 Common Weakness Enumeration , ^[65] un depósito de vulnerabilidades en el código fuente que hacen que las aplicaciones estén expuestas a violaciones de seguridad.

La medición de las características críticas de la aplicación implica medir los atributos estructurales de la arquitectura de la aplicación, la codificación y la documentación en línea, como se muestra en la imagen de arriba. 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 calculando la medida de la característica si se quiere que sea un predictor valioso de los resultados de calidad que afectan al negocio. El enfoque en capas para calcular las medidas características que se muestra en la figura anterior fue propuesto por primera vez por Boehm y sus colegas en TRW (Boehm, 1978) ^[66] 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 realiza a través del análisis del código fuente , la arquitectura , el marco del software , 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, a nivel de componente, que normalmente realizan las herramientas de desarrollo, que se ocupan principalmente de las consideraciones de implementación y son cruciales durante las actividades de depuración y prueba .

Fiabilidad

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

La evaluación de la confiabilidad requiere verificaciones de al menos las siguientes mejores prácticas de ingeniería de software y atributos técnicos:

• Prácticas de arquitectura de aplicaciones
• Prácticas de codificación
• Complejidad de algoritmos
• Complejidad de las prácticas de programación
• Cumplimiento de las mejores prácticas de programación estructurada y orientada a objetos (cuando corresponda)
• Relación de reutilización de componentes o patrones
• Programación sucia
• Manejo de errores y excepciones (para todas las capas: GUI, lógica y datos)
• Cumplimiento de diseño multicapa
• Gestión de límites de recursos
• El software evita patrones que conducirán a comportamientos inesperados
• El software gestiona la integridad y la coherencia de los datos
• Nivel de complejidad de la transacción

Dependiendo de la arquitectura de la aplicación y los componentes de terceros utilizados (como bibliotecas o marcos externos), las comprobaciones personalizadas deben definirse según las líneas trazadas por la lista anterior de mejores prácticas para garantizar una mejor evaluación de la confiabilidad del software entregado.

Eficiencia

Al igual que con la confiabilidad, las causas de la ineficiencia del rendimiento se encuentran a menudo en violaciones de las buenas prácticas de codificación y arquitectura que se pueden detectar 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 problemas de escalabilidad futuros, especialmente para aplicaciones que requieren una alta velocidad de ejecución para manejar algoritmos complejos o grandes volúmenes de datos.

La evaluación de la eficiencia del desempeño requiere verificar al menos 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 de acceso a datos y gestión de datos
• Gestión de memoria, red y espacio en disco
• Cumplimiento de las prácticas de codificación ^[67] ( mejores prácticas de codificación )

Seguridad

La calidad del software incluye la seguridad del software. ^[68] Muchas vulnerabilidades de seguridad son el resultado de prácticas de codificación y arquitectura deficientes, como la inyección de SQL o la secuencia de comandos entre sitios. ^{[69] [70]} Estos están bien documentados en listas mantenidas por CWE, ^[71] y el SEI / Computer Emergency Center (CERT) en Carnegie Mellon University. ^[67]

La evaluación de la seguridad requiere al menos verificar las siguientes mejores prácticas de ingeniería de software y atributos técnicos:

• Implementación, gestión de un proceso de desarrollo reforzado y consciente de la seguridad, por ejemplo, Security Development Lifecycle (Microsoft) o Secure Engineering Framework de IBM. ^[72]
• Prácticas seguras de arquitectura de aplicaciones ^{[73] [74]}
• 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.) ^{[75] [76]}
• Prácticas de programación buenas y seguras ^[67]
• Manejo de errores y excepciones

Mantenibilidad

La capacidad de mantenimiento incluye conceptos de modularidad, comprensibilidad, capacidad de cambio, 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 capacidad de mantenimiento deficiente suele ser el resultado de miles de infracciones menores con las mejores prácticas en la documentación, la estrategia para evitar la complejidad y las prácticas de programación básicas que marcan la diferencia entre un código limpio y fácil de leer y un código desorganizado y difícil de leer. . ^[77]

La evaluación de la capacidad de mantenimiento requiere verificar las siguientes mejores prácticas de ingeniería de software y atributos técnicos:

• Prácticas de arquitectura de aplicaciones
• Documentación de arquitectura, programas y código incorporada en el código fuente
• Legibilidad del código
• El código huele
• Nivel de complejidad de las transacciones
• Complejidad de algoritmos
• Complejidad de las prácticas de programación
• Cumplimiento de las mejores prácticas de programación estructurada y orientada a objetos (cuando corresponda)
• Relación de reutilización de componentes o patrones
• Nivel controlado de codificación dinámica
• Relación de acoplamiento
• Programación sucia
• Documentación
• Hardware, SO, middleware, componentes de software e independencia de la base de datos
• Cumplimiento de diseño multicapa
• Portabilidad
• Prácticas de programación (nivel de código)
• Reducción de funciones y código duplicado
• Limpieza de la organización de archivos de código fuente

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, ^[78] y a menudo tienen su origen en la incapacidad de los desarrolladores, la falta de tiempo y objetivos, su descuido y discrepancias en el costo de creación y los beneficios. de la documentación y, en particular, del código fuente mantenible . ^[79]

Tamaño

La medición del tamaño del software requiere que se recopile 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. tamaño funcional:

• Hay varios métodos técnicos de dimensionamiento 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, el número de archivos, funciones, clases, tablas, etc., a partir de los cuales se pueden calcular los puntos de función contraproducentes;
• El más común para medir el tamaño funcional es el análisis de puntos funcionales . El análisis de puntos de función mide el tamaño del software que se puede entregar desde la perspectiva del usuario. El tamaño 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 / estimador como del valor (funcionalidad que se entregará) y refleja la funcionalidad comercial 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 de tamaño está 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 es compatible con el Grupo Internacional de Usuarios de Puntos de Función ( IFPUG ). Se puede aplicar al principio del ciclo de vida del desarrollo de software y no depende de líneas de código como el método Backfiring algo inexacto. El método es independiente de la tecnología y se puede utilizar para el análisis comparativo entre organizaciones e industrias.

Desde el inicio del análisis de puntos de función, han evolucionado varias variaciones y la familia de técnicas de dimensionamiento funcional se ha ampliado para incluir medidas de dimensionamiento como COSMIC, NESMA, Use Case Points, FP Lite, Early y Quick FPs y, más recientemente, Story Points. Sin embargo, Function Points tiene un historial de precisión estadística y se ha utilizado como una unidad común de medida de trabajo en numerosos compromisos de gestión de desarrollo de aplicaciones (ADM) o subcontratación, y sirve como la "moneda" mediante la cual se prestan los servicios y se mide el rendimiento.

Una limitación común de la metodología Function Point es que es un proceso manual y, por lo tanto, puede ser laborioso y costoso en iniciativas a gran escala, como el desarrollo de aplicaciones o los compromisos 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 enfocado en introducir un estándar de métricas computables para automatizar la medición del tamaño del software mientras el IFPUG sigue promoviendo un enfoque manual ya que la mayor parte de su actividad se basa en en certificaciones de contadores FP.

CISQ define Sizing como estimar el tamaño del software para respaldar la estimación de costos, el seguimiento del progreso u otras actividades de gestión de proyectos de software relacionadas. 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 medida. ^[80]

Identificación de errores críticos de programación

Los errores críticos de programación son malas prácticas específicas de arquitectura y / o codificación que dan como resultado el mayor riesgo de interrupción del negocio, inmediato o de largo plazo. ^[81]

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

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

• Fiabilidad
  • Evite los patrones de software que conducirán a un comportamiento inesperado ( variable no inicializada , punteros nulos, etc.)
  • Los métodos, procedimientos y funciones para insertar, actualizar, eliminar, crear tabla o seleccionar deben incluir la gestión de errores
  • Las funciones de subprocesos múltiples 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 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
  • Asegure la validación de entrada para evitar fallas de secuencias de comandos entre sitios o fallas en las inyecciones de SQL
• Mantenibilidad
  • Se deben evitar los árboles de herencia profunda y la anidación para mejorar la comprensión
  • Los módulos deben estar débilmente acoplados (fanout, intermediarios) para evitar la propagación de modificaciones
  • Aplicar convenciones de nomenclatura homogéneas

Modelos de calidad operacionalizados

Las propuestas más recientes de modelos de calidad como Squale y Quamoco ^[82] propagan una integración directa de la definición de los atributos de calidad y la 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. Estos modelos de calidad se han aplicado en contextos industriales pero no han recibido una adopción generalizada.

Trivialidades

• "Una ciencia es tan madura como sus herramientas de medición". ^[83]
• " Lo sé cuando lo veo ".
• "No se puede controlar lo que no se puede medir". ^[7] ( Tom DeMarco )
• "No se puede inspeccionar la calidad de un producto". ( W. Edwards Deming ) ^[84]
• "La amargura de la mala calidad permanece mucho después de que se haya olvidado la dulzura de cumplir con el cronograma". (Anónimo) ^[84]
• "Si no comienza con una especificación, cada fragmento de código que escribe es un parche". ( Leslie Lamport )

Ver también

• ISO / IEC 9126
• Mejora del proceso de software y determinación de la capacidad - ISO / IEC 15504
• Anomalía en el software
• Accesibilidad
• Disponibilidad
• Mejores prácticas de codificación
• Cohesión y acoplamiento
• Complejidad ciclomática
• Convenciones de codificación
• Error informático
• Confianza
• GQM
• Estilo de programación
• Calidad : control de calidad , gestión de calidad total .
• Gestión de requerimientos
• Scope_ (project_management)
• Seguridad
• Ingenieria de seguridad
• Aseguramiento de la calidad del software
• Arquitectura de software
• Control de calidad del software
• Métricas de software
• Reutilización de software
• Estándar de software
• Pruebas de software
• Testabilidad
• Análisis de programa estático

Otras lecturas

• 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).
• 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.
• Ho-Won Jung, Seung-Gweon Kim y Chang-Sin Chung. Medición de la calidad del producto de software: una encuesta de ISO / IEC 9126 . IEEE Software , 21 (5): 10-13, septiembre / octubre de 2004.
• Stephen H. Kan. Métricas y modelos en ingeniería de calidad de software . Addison-Wesley, Boston, MA, segunda edición, 2002.
• Omar Alshathry, Helge Janicke, "Optimizing Software Quality Assurance", compsacw, págs. 87–92, 34ª Conferencia anual sobre software y aplicaciones de la IEEE de 2010, 2010.
• Robert L. Glass. Software de calidad para 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
• Capers Jones y Olivier Bonsignour, "The Economics of Software Quality", Addison-Wesley Professional, primera edición, 31 de diciembre de 2011, ISBN  978-0-13-258220-9
• Medición de la calidad del producto de software: la serie ISO 25000 y CMMI (sitio SEI)
• MSQF: un marco de calidad de software basado en mediciones Cornell University Library
• Stefan Wagner. Control de calidad de productos de software . Springer, 2013.
• Girish Suryanarayana, Proceso de software versus calidad de diseño: ¿Tira y afloja? ^[85]
• Asociación de Gerentes Marítimos en Tecnologías de la Información y Comunicaciones (AMMITEC). Directrices de calidad del software marítimo . Septiembre de 2017
• Software Quality Professional, ^[86] American Society for Quality (ASQ)
• Revista de calidad de software ^[87] de Springer Nature
• CAT Lab - Laboratorio de herramientas de análisis de código CNES (en Github)

Referencias

Notas

1. Board (IREB), Ingeniería de Requisitos Internacionales. "Aprendiendo de la historia: El caso de Ingeniería de Requisitos de Software - Revista Ingeniería de Requisitos" . Aprendiendo de la historia: El caso de Ingeniería de Requisitos de Software - Revista Ingeniería de Requisitos . Consultado el 25 de febrero de 2021 .
2. Pressman, Roger S. (2005). Ingeniería de software: el enfoque de un practicante (Sexta edición internacional). Educación McGraw-Hill. pag. 388. ISBN 0071267824.
3. "Acerca de la versión 1.0 de la especificación de medidas de calidad del código fuente automatizado" . www.omg.org . Consultado el 25 de febrero de 2021 .
4. "Cómo realizar pruebas de extremo a extremo" . smartbear.com . Consultado el 25 de febrero de 2021 .
5. "Cómo ofrecer sistemas de TI resistentes, seguros, eficientes y que se cambian fácilmente de acuerdo con las recomendaciones de CISQ" (PDF) . Archivado (PDF) desde el original el 28 de diciembre de 2013 . Consultado el 18 de octubre de 2013 .
6. 14: 00-17: 00. "ISO / IEC 25010: 2011" . ISO . Consultado el 23 de febrero de 2021 .
7. Armadura, Phillip G. (1 de junio de 2012). "Una medida de control" . Comunicaciones de la ACM . 55 (6): 26-28. doi : 10.1145 / 2184319.2184329 . ISSN  0001-0782 .
8. Voas, J. (noviembre de 2011). "Salsa secreta del software: las" -ilidades "[calidad del software]" . Software IEEE . 21 (6): 14-15. doi : 10.1109 / MS.2004.54 . ISSN  1937-4194 .
9. "Estándares de calidad de código | CISQ - Consorcio para la calidad de la información y el software" . www.it-cisq.org . Consultado el 25 de febrero de 2021 .
10. "Estándares de dimensionamiento de software | CISQ - Consorcio para la calidad de la información y el software" . www.it-cisq.org . Consultado el 25 de febrero de 2021 .
11. J. Bohnet, J. Döllner Archivado el 27 de abril de 2014 en Wayback Machine , "Supervisión de la calidad del código y la actividad de desarrollo mediante mapas de software". Actas del taller IEEE ACM ICSE sobre gestión de la deuda técnica, págs. 9-16, 2011.
12. "IIA - Guía de auditoría de tecnología global: Gestión del cambio de TI: fundamental para el éxito organizacional" . na.theiia.org . Consultado el 26 de febrero de 2021 .
13. Boursier, Jérôme (11 de enero de 2018). "Fallout de Meltdown y Spectre: persisten los problemas de parcheo" . Malwarebytes Labs . Consultado el 26 de febrero de 2021 .
14. mestew. "Mejores prácticas para actualizaciones de software - Configuration Manager" . docs.microsoft.com . Consultado el 26 de febrero de 2021 .
15. Wright, Hyrum K. (25 de agosto de 2009). "Procesos, modelos y métricas de ingeniería de versiones" . Actas del simposio de doctorado para ESEC / FSE sobre simposio de doctorado . Simposio de Doctorado ESEC / FSE '09. Amsterdam, Países Bajos: Association for Computing Machinery: 27-28. doi : 10.1145 / 1595782.1595793 . ISBN 978-1-60558-731-8.
16. van der Hoek, André; Hall, Richard S .; Heimbigner, Dennis; Wolf, Alexander L. (noviembre de 1997). "Gestión de versiones de software" . Notas de ingeniería del software ACM SIGSOFT . 22 (6): 159-175. doi : 10.1145 / 267896.267909 . ISSN  0163-5948 .
17. Moore, Mike Sutton y Tym (30 de julio de 2008). "7 formas de mejorar la gestión de versiones de software" . CIO . Consultado el 26 de febrero de 2021 .
18. Clark, Mitchell (24 de febrero de 2021). "iRobot dice que pasarán algunas semanas hasta que pueda limpiar su última actualización del software Roomba" . The Verge . Consultado el 25 de febrero de 2021 .
19. "Top 25 errores de software | Instituto SANS" . www.sans.org . Consultado el 25 de febrero de 2021 .
20. " ' Apagarlo y encenderlo de nuevo cada 149 horas' es un remedio preocupante para un error de software de un avión Airbus de $ 300 millones" . Gizmodo . Consultado el 25 de febrero de 2021 .
21. Software, Gimpel. "MISRA C, Toyota y la muerte de la tarea X" . Consultado el 25 de febrero de 2021 .
22. "Una actualización sobre Toyota y aceleración involuntaria« Código Barr " . embeddedgurus.com . Consultado el 25 de febrero de 2021 .
23. Dispositivos médicos: Therac-25 * Archivado el 16 de febrero de 2008 en la Wayback Machine , Nancy Leveson, Universidad de Washington
24. Software integrado Archivado el 5 dejulio de 2010en Wayback Machine , Edward A. Lee, Para aparecer en Advances in Computers (M. Zelkowitz, editor), Vol. 56, Academic Press, Londres, 2002, revisado de UCB ERL Memorandum M01 / 26 Universidad de California, Berkeley, CA 94720, EE. UU., 1 de noviembre de 2001
25. "Software de certificación de aeronaves y hardware electrónico aerotransportado" . Archivado desde el original el 4 de octubre de 2014 . Consultado el 28 de septiembre de 2014 .
26. "El costo de la mala calidad del software en los Estados Unidos: un informe de 2020 | CISQ - Consorcio para la calidad de la información y el software" . www.it-cisq.org . Consultado el 25 de febrero de 2021 .
27. "¿Qué es el desperdicio? | Agile Alliance" . Alianza ágil | . Consultado el 25 de febrero de 2021 .
28. 26 de enero, Scott Matteson en Software en; 2018; Pst, 7:54 am. "Informe: la falla del software causó $ 1,7 billones en pérdidas financieras en 2017" . TechRepublic . Consultado el 25 de febrero de 2021 .
29. Cohane, Ryan (16 de noviembre de 2017). "Costo financiero de los errores de software" . Medio . Consultado el 25 de febrero de 2021 .
30. Eloff, Jan; Bella, Madeleine Bihina (2018), "Software Failures: An Overview" , Investigación de fallos de software , Cham: Springer International Publishing, págs. 7–24, doi : 10.1007 / 978-3-319-61334-5_2 , ISBN 978-3-319-61333-8, consultado el 25 de febrero de 2021
31. "La mala calidad del software le costó a las empresas 2 billones de dólares el año pasado y puso en riesgo la seguridad" . CIO Dive . Consultado el 26 de febrero de 2021 .
32. "La investigación CISQ patrocinada por Synopsys estima el costo de la mala calidad del software en los US $ 2.08 billones en 2020" . finance.yahoo.com . Consultado el 26 de febrero de 2021 .
33. "¿Cuánto cuesta una violación de datos en 2020?" . Guardián digital . 2020-08-06 . Consultado el 8 de marzo de 2021 .
34. "Costo de un informe de filtración de datos 2020 | IBM" . www.ibm.com . 2020 . Consultado el 8 de marzo de 2021 .
35. "ISO - Familia ISO 9000 - Gestión de la calidad" . ISO . Consultado el 24 de febrero de 2021 .
36. 14: 00-17: 00. "ISO / IEC / IEEE 24765: 2017" . ISO . Consultado el 24 de febrero de 2021 .
37. "Dominar el software automotriz | McKinsey" . www.mckinsey.com . Consultado el 25 de febrero de 2021 .
38. 14: 00-17: 00. "ISO / IEC 25010: 2011" . ISO . Consultado el 24 de febrero de 2021 .
39. Wallace, DR (2002). "Modelado práctico de confiabilidad del software" . Actas 26º Taller Anual de Ingeniería de Software Goddard de la NASA . Greenbelt, MD, EE.UU .: IEEE Comput. Soc: 147-155. doi : 10.1109 / SEW.2001.992668 . ISBN 978-0-7695-1456-7.
40. "¿Qué es la calidad del software? | ASQ" . asq.org . Consultado el 24 de febrero de 2021 .
41. "SAMATE - Página principal del proyecto de evaluación de herramientas y métricas de aseguramiento de software" . samate.nist.gov . Consultado el 26 de febrero de 2021 .
42. Extensión de software a la guía PMBOK . Project Management Institute (5ª ed.). Newtown Square, Pensilvania. 2013. ISBN 978-1-62825-041-1. OCLC  959513383 .
43. SHEWHART, WALTER A. (2015). Control económico de la calidad del producto fabricado . [Lugar de publicación no identificado]: MARTINO FINE Books. ISBN 1-61427-811-3. OCLC  1108913766 .
44. Kitchenham, B .; Pfleeger, SL (enero de 1996). "Calidad del software: el objetivo esquivo [sección de cuestiones especiales]" . Software IEEE . 13 (1): 12-21. doi : 10.1109 / 52.476281 . ISSN  1937-4194 .
45. Garvin, David A. (1988). Gestión de la calidad: la ventaja estratégica y competitiva . Nueva York: Free Press. ISBN 0-02-911380-6. OCLC  16005388 .
46. B. Kitchenham y S. Pfleeger, "Calidad del software: el objetivo esquivo", IEEE Software, vol. 13, no. 1, págs. 12-21, 1996.
47. Kan, Stephen H. (2003). Métricas y modelos en ingeniería de calidad del software (2ª ed.). Boston: Addison-Wesley. ISBN 0-201-72915-6. OCLC  50149641 .
48. Organización Internacional de Normalización, "ISO / IEC 9001: Sistemas de gestión de calidad - Requisitos", 1999.
49. WE Deming, "Salir de la crisis: calidad, productividad y posición competitiva". Prensa de la Universidad de Cambridge, 1988.
50. AV Feigenbaum, "Control de calidad total", McGraw-Hill, 1983.
51. JM Juran, "Manual de control de calidad de Juran", McGraw-Hill, 1988.
52. Weinberg, G. (1991). "Gestión de Software de Calidad Volumen 1: Pensamiento de Sistemas" . indefinido . Consultado el 24 de febrero de 2021 .
53. "Gestión de software de calidad (serie de software de calidad) Volumen 2: Medición de primer orden" . GeraldMWeinberg.com . 2019-12-05 . Consultado el 24 de febrero de 2021 .
54. Crosby, P., Quality is Free , McGraw-Hill, 1979
55. "SUP.9 - Gestión de resolución de problemas - Kugler Maag Cie" . www.kuglermaag.com . Consultado el 25 de febrero de 2021 .
56. Hoipt (29 de noviembre de 2019). "Las organizaciones suelen utilizar los términos 'Garantía de calidad' (QA) frente a 'Control de calidad' (QC) ..." . Medio . Consultado el 25 de febrero de 2021 .
57. Wallace, D .; Watson, AH; Mccabe, TJ (1 de agosto de 1996). "Pruebas estructuradas: una metodología de prueba utilizando la métrica de complejidad ciclomática" .
58. Bellairs, Richard. "¿Qué es la calidad del código? Y cómo mejorar la calidad del código" . Perforce Software . Consultado el 28 de febrero de 2021 .
59. "Libro blanco de OMG | CISQ - Consorcio para la calidad de la información y el software" . www.it-cisq.org . Consultado el 26 de febrero de 2021 .
60. "Cómo ofrecer sistemas de TI resistentes, seguros, eficientes y ágiles de acuerdo con las recomendaciones de CISQ - Informe técnico | Grupo de gestión de objetos" (PDF) . Archivado (PDF) desde el original el 28 de diciembre de 2013 . Consultado el 18 de octubre de 2013 .
61. "Medición del tamaño del software: un marco para contar declaraciones de origen" . resources.sei.cmu.edu . Consultado el 24 de febrero de 2021 .
62. Halstead, Maurice H. (1977). Elementos de la ciencia del software (serie de sistemas operativos y de programación) . Estados Unidos: Elsevier Science Inc. ISBN 978-0-444-00205-1.
63. Chidamber, SR; Kemerer, CF (junio de 1994). "Una suite de métricas para el diseño orientado a objetos" . Transacciones IEEE sobre ingeniería de software . 20 (6): 476–493. doi : 10.1109 / 32.295895 . hdl : 1721,1 / 48424 . ISSN  1939-3520 .
64. Nygard, Michael (2007). ¡Liberarlo! . un Safari de O'Reilly Media Company (1ª ed.). ISBN 0978739213. OCLC  1102387436 .
65. "CWE - enumeración de debilidades comunes" . cwe.mitre.org . Archivado desde el original el 10 de mayo de 2016 . Consultado el 20 de mayo de 2016 .
66. Boehm, B., Brown, JR, Kaspar, H., Lipow, M., MacLeod, GJ y Merritt, MJ (1978). Características de la calidad del software. Holanda Septentrional.
67. "Estándares de codificación SEI CERT - Codificación segura CERT - Confluencia" . wiki.sei.cmu.edu . Consultado el 24 de febrero de 2021 .
68. "Calidad del código y seguridad del código: ¿Cómo se relacionan? | Sinopsis" . Blog de integridad del software . 2019-05-24 . Consultado el 9 de marzo de 2021 .
69. "Costo de un informe de filtración de datos 2020 | IBM" . www.ibm.com . 2020 . Consultado el 9 de marzo de 2021 .
70. "Conclusiones clave del costo 2020 de un informe de violación de datos" . Atún rojo . 2020-08-27 . Consultado el 9 de marzo de 2021 .
71. "CWE - enumeración de debilidades comunes" . Cwe.mitre.org. Archivado desde el original el 14 de octubre de 2013 . Consultado el 18 de octubre de 2013 .
72. Seguridad en el desarrollo: IBM Secure Engineering Framework | IBM Redbooks . 2016-09-30.
73. Arquitectura de seguridad empresarial con las soluciones de seguridad de IBM Tivoli | IBM Redbooks . 2016-09-30.
74. "Definiciones de Diseño de Arquitectura Segura | CISA" . us-cert.cisa.gov . Consultado el 9 de marzo de 2021 .
75. "Fundación OWASP | Fundación de código abierto para la seguridad de las aplicaciones" . owasp.org . Consultado el 24 de febrero de 2021 .
76. "Top 25 de CWE" . Sans.org . Consultado el 18 de octubre de 2013 .
77. IfSQ Level-2 A Foundation-Level Standard for Computer Program Source Source Archivado el27 de octubre de 2011en Wayback Machine , segunda edición de agosto de 2008, Graham Bolton, Stuart Johnston, IfSQ, Institute for Software Quality.
78. Fowler, Martin (14 de octubre de 2009). "TechnicalDebtQuadrant" . Archivado desde el original el 2 de febrero de 2013 . Consultado el 4 de febrero de 2013 .
79. Prause, Christian; Durdik, Zoya (3 de junio de 2012). "Diseño arquitectónico y documentación: ¿Residuos en desarrollo ágil?". 2012 Conferencia Internacional sobre Software y Procesos de Sistemas (ICSSP) . Sociedad de Informática IEEE. págs. 130-134. doi : 10.1109 / ICSSP.2012.6225956 . ISBN 978-1-4673-2352-9. S2CID  15216552 .
80. "Estándares de dimensionamiento de software | CISQ - Consorcio para la calidad de la información y el software" . www.it-cisq.org . Consultado el 28 de enero de 2021 .
81. "Por qué falla el software" . IEEE Spectrum: Noticias de tecnología, ingeniería y ciencia . Consultado el 20 de marzo de 2021 .
82. Wagner, Stefan; Goeb, Andreas; Heinemann, Lars; Kläs, Michael; Lampasona, Constanza; Lochmann, Klaus; Mayr, Alois; Plösch, Reinhold; Seidl, Andreas (2015). "Evaluación y modelos de calidad de producto operacionalizados: el enfoque de Quamoco" (PDF) . Tecnología de la información y el software . 62 : 101-123. arXiv : 1611.09230 . doi : 10.1016 / j.infsof.2015.02.009 . S2CID  10992384 .
83. Ebert, Christof (2010). Medición de software: Establecer - Extraer - Evaluar - Ejecutar . ISBN 9783642090806. OCLC  941931829 .
84. "Gestión de lo inmanejable: más reglas generales" . www.managingtheunmanageable.net . Consultado el 26 de febrero de 2021 .
85. Suryanarayana, Girish (2015). "Proceso de software versus calidad de diseño: ¿Tira y afloja?" . Software IEEE . 32 (4): 7-11. doi : 10.1109 / MS.2015.87 . S2CID  9226051 .
86. "Software Quality Professional | ASQ" . asq.org . Consultado el 28 de enero de 2021 .
87. "Revista de calidad del software" . Springer . Consultado el 28 de enero de 2021 .

Bibliografía

• Albrecht, AJ (1979), Midiendo la productividad del desarrollo de aplicaciones. En Actas del Simposio de Desarrollo de Aplicaciones IBM conjunto SHARE / GUIDE. , IBM
• Ben-Menachem, M .; Marliss, GS (1997), Calidad de software, producción de software práctico y consistente , Thomson Computer Press
• Boehm, B .; Brown, JR; Kaspar, H .; Lipow, M .; MacLeod, GJ; Merritt, MJ (1978), Características de la calidad del software , Holanda Septentrional.
• Chidamber, S .; Kemerer, C. (1994), A Metrics Suite for Object Oriented Design. Transacciones IEEE sobre ingeniería de software, 20 (6) , págs. 476–493
• Ebert, Christof; Dumke, Reiner, Software Measurement: Establecer - Extraer - Evaluar - Ejecutar , Edición Kindle, p. 91
• Garmus, D .; Herron, D. (2001), Análisis de puntos de función , Addison Wesley
• Halstead, ME (1977), Elementos de la ciencia del software , Elsevier North-Holland
• Hamill, M .; Goseva-Popstojanova, K. (2009), Fallas comunes en fallas de software y datos de fallas. Transacciones IEEE de ingeniería de software, 35 (4) , págs. 484–496
• Jackson, DJ (2009), Un camino directo hacia un software confiable. Comunicaciones de la ACM, 52 (4).
• Martin, R. (2001), Gestión de vulnerabilidades en sistemas en red , IEEE Computer.
• McCabe, T. (diciembre de 1976), Una medida de complejidad. Transacciones IEEE sobre ingeniería de software
• McConnell, Steve (1993), Code Complete (Primera edición), Microsoft Press
• Nygard, MT (2007), Release It! Diseñe e implemente software listo para la producción , los programadores pragmáticos.
• Park, RE (1992), Software Size Measurement: A Framework for Counting Source Statements. (CMU / SEI-92-TR-020). , Instituto de Ingeniería de Software, Universidad Carnegie Mellon
• Pressman, Roger S. (2005). Ingeniería de software: el enfoque de un practicante (Sexta edición internacional). Educación McGraw-Hill. ISBN 0071267824.
• Spinellis, D. (2006), Calidad de código , Addison Wesley

enlaces externos

• Cuando el código es el rey: dominar la excelencia del software automotriz (McKinsey, 2021)
• Calidad del software del sistema integrado: ¿Por qué es tan a menudo terrible? ¿Qué podemos hacer al respecto? (por Philip Koopman )
• Estándares de calidad del código de CISQ ™
• Blog de CISQ: https://blog.it-cisq.org
• Guía para el aseguramiento de la calidad del software (ESA)
• Guía para aplicar los estándares de ingeniería de software de la ESA a pequeños proyectos de software (ESA)
• Una descripción general de los servicios de garantía de productos de software de la ESA (NASA / ESA)
• Nuestro enfoque de la calidad en Volkswagen Software Dev Center Lisboa
• Guías de estilo de Google
• Garantizar la calidad del producto 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 (articulada en IREB por Harry Sneed)
• Prueba estructurada: una metodología de prueba que utiliza la métrica de complejidad ciclomática (1996)
• Analizar la calidad de las aplicaciones mediante el uso de herramientas de análisis de código (Microsoft, Documentation, Visual Studio, 2016)