stringtranslate.com

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 ]

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]

Motivación

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

Definiciones

YO ASI

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]

Aseguramiento de la calidad

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]

Instituto Nacional de Estándares y Tecnología (NIST)

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

PMI

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]

Otros generales e históricos

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]

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]

Otros significados y controversias

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]

Medición

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]

Introducción

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

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):

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]

Análisis basado en código

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 .

Fiabilidad

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.

Eficiencia

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:

Seguridad

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:

Mantenibilidad

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]

Tamaño

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:

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]

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

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:

Modelos de calidad operacionalizados

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.

Véase también

Lectura adicional

Referencias

Notas

  1. ^ "Aprendiendo de la historia: El caso de la Ingeniería de Requisitos de Software – Revista de Ingeniería de Requisitos". Aprendiendo de la historia: El caso de la Ingeniería de Requisitos de Software – Revista de Ingeniería de Requisitos . Consultado el 25 de febrero de 2021 .
  2. ^ Pressman, Roger S. (2005). Ingeniería de software: un enfoque práctico (sexta edición internacional). McGraw-Hill Education. pág. 388. ISBN 0071267824.
  3. ^ "Acerca de la especificación de medidas de calidad de código fuente automatizadas versión 1.0". 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 fáciles de modificar 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. ^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  7. ^ "ISO/IEC 25010:2011". ISO . Consultado el 23 de febrero de 2021 .
  8. ^ Armour, 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. S2CID  6059054.
  9. ^ Voas, J. (noviembre de 2011). "La salsa secreta del software: las "-ilidades" [calidad del software]". IEEE Software . 21 (6): 14–15. doi :10.1109/MS.2004.54. ISSN  1937-4194.
  10. ^ "Estándares de calidad del 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 .
  11. ^ "Estándares de dimensionamiento de software | CISQ - Consorcio para la información y la calidad del software". www.it-cisq.org . Consultado el 25 de febrero de 2021 .
  12. ^ J. Bohnet, J. Döllner Archivado el 27 de abril de 2014 en Wayback Machine , "Monitoreo 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.
  13. ^ "IIA - Guía de auditoría tecnológica global: Gestión de cambios en TI: fundamental para el éxito organizacional". na.theiia.org . Consultado el 26 de febrero de 2021 .
  14. ^ Boursier, Jérôme (11 de enero de 2018). «Consecuencias de Meltdown y Spectre: persisten los problemas de parcheo». Malwarebytes Labs . Consultado el 26 de febrero de 2021 .
  15. ^ "Mejores prácticas para actualizaciones de software - Configuration Manager". docs.microsoft.com . Consultado el 26 de febrero de 2021 .
  16. ^ Wright, Hyrum K. (25 de agosto de 2009). "Procesos, modelos y métricas de ingeniería de versiones". Actas del simposio doctoral de ESEC/FSE en Simposio doctoral . Simposio doctoral ESEC/FSE '09. Ámsterdam, Países Bajos: Association for Computing Machinery. págs. 27–28. doi :10.1145/1595782.1595793. ISBN 978-1-60558-731-8. Número de identificación del sujeto  10483918.
  17. ^ van der Hoek, André; Hall, Richard S.; Heimbigner, Dennis; Wolf, Alexander L. (noviembre de 1997). "Gestión de lanzamientos de software". Notas de ingeniería de software de ACM SIGSOFT . 22 (6): 159-175. doi : 10.1145/267896.267909 . ISSN  0163-5948.
  18. ^ Sutton, Mike; Moore, Tym (30 de julio de 2008). "7 formas de mejorar la gestión de lanzamiento de software". CIO . Consultado el 26 de febrero de 2021 .
  19. ^ Clark, Mitchell (24 de febrero de 2021). "iRobot dice que pasarán algunas semanas hasta que pueda solucionar el problema de la última actualización del software de Roomba". The Verge . Consultado el 25 de febrero de 2021 .
  20. ^ "Los 25 errores de software más comunes". www.sans.org . Consultado el 25 de febrero de 2021 .
  21. ^ "'Apagarlo y encenderlo de nuevo cada 149 horas' es una solución preocupante para el error de software de un avión Airbus de 300 millones de dólares". Gizmodo . 30 de julio de 2019 . Consultado el 25 de febrero de 2021 .
  22. ^ "MISRA C, Toyota y la muerte de la Tarea X" . Consultado el 25 de febrero de 2021 .
  23. ^ "Actualización sobre Toyota y la aceleración involuntaria «Barr Code». embryogurus.com . Consultado el 25 de febrero de 2021 .
  24. ^ Dispositivos médicos: Therac-25* Archivado el 16 de febrero de 2008 en Wayback Machine , Nancy Leveson, Universidad de Washington
  25. ^ Software integrado Archivado el 5 de julio de 2010 en Wayback Machine , Edward A. Lee, Para aparecer en Advances in Computers ( Marvin Victor Zelkowitz , editor), Vol. 56, Academic Press, Londres, 2002, Revisado a partir del Memorando UCB ERL M01/26 Universidad de California, Berkeley, CA 94720, EE. UU., 1 de noviembre de 2001
  26. ^ "Software de certificación de aeronaves y hardware electrónico de a bordo". Archivado desde el original el 4 de octubre de 2014 . Consultado el 28 de septiembre de 2014 .
  27. ^ "El costo de la mala calidad del software en los EE. UU.: un informe de 2020 | CISQ - Consorcio para la información y la calidad del software". www.it-cisq.org . Consultado el 25 de febrero de 2021 .
  28. ^ "¿Qué es el desperdicio? | Agile Alliance". Agile Alliance | . 20 de abril de 2016 . Consultado el 25 de febrero de 2021 .
  29. ^ Matteson, Scott (26 de enero de 2018). "Informe: una falla de software causó pérdidas financieras por 1,7 billones de dólares en 2017". TechRepublic . Consultado el 25 de febrero de 2021 .
  30. ^ Cohane, Ryan (16 de noviembre de 2017). "Costo financiero de los errores de software". Medium . Consultado el 25 de febrero de 2021 .
  31. ^ Eloff, Jan; Bella, Madeleine Bihina (2018), "Fallas de software: una descripción general", Investigación de fallas 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
  32. ^ "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 .
  33. ^ "Investigación CISQ patrocinada por Synopsys estima el costo de la mala calidad del software en los EE. UU. en 2,08 billones de dólares en 2020". finance.yahoo.com . Consultado el 26 de febrero de 2021 .
  34. ^ "¿Cuánto cuesta una filtración de datos en 2020?". Digital Guardian . 2020-08-06 . Consultado el 2021-03-08 .
  35. ^ "Informe sobre el costo de una filtración de datos 2020 | IBM". www.ibm.com . 2020 . Consultado el 8 de marzo de 2021 .
  36. ^ "ISO - Familia ISO 9000 — Gestión de la calidad". ISO . Consultado el 24 de febrero de 2021 .
  37. ^ "ISO/IEC/IEEE 24765:2017". ISO . Consultado el 24 de febrero de 2021 .
  38. ^ ab "Dominar el software automotriz". www.mckinsey.com . Consultado el 25 de febrero de 2021 .
  39. ^ "ISO/IEC 25010:2011". ISO . Consultado el 24 de febrero de 2021 .
  40. ^ Wallace, DR (2002). "Modelado práctico de confiabilidad de software". Actas del 26.º Taller anual de ingeniería de software Goddard de la NASA . Greenbelt, MD, EE. UU.: IEEE Comput. Soc. pp. 147–155. doi :10.1109/SEW.2001.992668. ISBN 978-0-7695-1456-7. Número de identificación del sujeto  57382117.
  41. ^ "ISO/IEC 25023:2016". ISO . Consultado el 6 de noviembre de 2023 .
  42. ^ "¿Qué es la calidad del software? | ASQ". asq.org . Consultado el 24 de febrero de 2021 .
  43. ^ "SAMATE - Página principal del proyecto Software Assurance Metrics And Tool Evaluation". NIST . 3 de febrero de 2021 . Consultado el 26 de febrero de 2021 .
  44. ^ Extensión de software para la guía PMBOK. Project Management Institute (5.ª ed.). Newtown Square, Pensilvania. 2013. ISBN 978-1-62825-041-1.OCLC 959513383  .{{cite book}}: CS1 maint: falta la ubicación del editor ( enlace ) CS1 maint: otros ( enlace )
  45. ^ Shewart, Walter A. (2015). Control económico de la calidad de los productos manufacturados. [Lugar de publicación no identificado]: Martino Fine Books. ISBN 978-1-61427-811-5.OCLC 1108913766  .
  46. ^ Kitchenham, B. ; Pfleeger, SL (enero de 1996). "Calidad del software: el objetivo elusivo [sección de números especiales]". IEEE Software . 13 (1): 12–21. doi :10.1109/52.476281. ISSN  1937-4194.
  47. ^ 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  .
  48. ^ ab B. Kitchenham y S. Pfleeger, "Calidad del software: el objetivo elusivo", IEEE Software, vol. 13, núm. 1, págs. 12–21, 1996.
  49. ^ Kan, Stephen H. (2003). Métricas y modelos en ingeniería de calidad de software (2.ª ed.). Boston: Addison-Wesley. ISBN 0-201-72915-6.OCLC 50149641  .
  50. ^ Organización Internacional de Normalización, "ISO/IEC 9001: Sistemas de gestión de calidad -- Requisitos", 1999.
  51. ^ WE Deming, "Salir de la crisis: calidad, productividad y posición competitiva". Cambridge University Press, 1988.
  52. ^ AV Feigenbaum, "Control de calidad total", McGraw-Hill, 1983.
  53. ^ JM Juran, "Manual de control de calidad de Juran", McGraw-Hill, 1988.
  54. ^ Weinberg, Gerald M. (1991). Gestión de software de calidad: Volumen 1, Pensamiento sistémico. Nueva York, NY: Dorset House. ISBN 0-932633-22-6.OCLC 23870230  .
  55. ^ Weinberg, Gerald M. (1993). Gestión de software de calidad: Volumen 2, Medición de primer orden. Nueva York, NY: Dorset House. ISBN 0-932633-22-6.OCLC 23870230  .
  56. ^ Crosby, P., La calidad es gratuita , McGraw-Hill, 1979
  57. ^ "SUP.9 – Gestión de resolución de problemas - Kugler Maag Cie". www.kuglermaag.com . Consultado el 25 de febrero de 2021 .
  58. ^ ab Hoipt (2019-11-29). "Las organizaciones suelen utilizar los términos 'garantía de calidad' (QA) frente a 'control de calidad' (QC)…". Medium . Consultado el 25 de febrero de 2021 .
  59. ^ Wallace, D.; Watson, AH; Mccabe, TJ (1 de agosto de 1996). "Pruebas estructuradas: una metodología de pruebas que utiliza la métrica de complejidad ciclomática". NIST .
  60. ^ Bellairs, Richard. "¿Qué es la calidad del código? Y cómo mejorarla". Perforce Software . Consultado el 28 de febrero de 2021 .
  61. ^ "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 .
  62. ^ "Cómo ofrecer sistemas de TI resilientes, seguros, eficientes y ágiles en línea con las recomendaciones de CISQ - Documento técnico | Object Management Group" (PDF) . Archivado (PDF) desde el original el 28 de diciembre de 2013 . Consultado el 18 de octubre de 2013 .
  63. ^ "Medición del tamaño del software: un marco para contar las declaraciones de origen". resources.sei.cmu.edu . 31 de agosto de 1992 . Consultado el 24 de febrero de 2021 .
  64. ^ Halstead, Maurice H. (1977). Elementos de la ciencia del software (serie sobre sistemas operativos y de programación). Estados Unidos: Elsevier Science Inc. ISBN 978-0-444-00205-1.
  65. ^ Chidamber, SR; Kemerer, CF (junio de 1994). "Un conjunto de métricas para el diseño orientado a objetos". IEEE Transactions on Software Engineering . 20 (6): 476–493. doi :10.1109/32.295895. hdl : 1721.1/48424 . ISSN  1939-3520. S2CID  9493847.
  66. ^ Nygard, Michael (2007). Release It!, un safari de O'Reilly Media Company (1.ª ed.). Pragmatic Bookshelf. ISBN 978-0978739218.OCLC 1102387436  .
  67. ^ "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 .
  68. ^ Boehm, B., Brown, JR, Kaspar, H., Lipow, M., MacLeod, GJ y Merritt, MJ (1978). Características de la calidad del software. Holanda Septentrional.
  69. ^ abc "Estándares de codificación SEI CERT - Codificación segura CERT - Confluence". wiki.sei.cmu.edu . Consultado el 24 de febrero de 2021 .
  70. ^ "Calidad y seguridad del código: ¿cómo se relacionan? | Synopsys". Blog de integridad del software . 2019-05-24 . Consultado el 2021-03-09 .
  71. ^ "Informe sobre el costo de una filtración de datos 2020 | IBM". www.ibm.com . 2020 . Consultado el 9 de marzo de 2021 .
  72. ^ "Conclusiones clave del informe sobre el costo de una filtración de datos de 2020". Bluefin . 2020-08-27 . Consultado el 2021-03-09 .
  73. ^ "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 .
  74. ^ Seguridad en el desarrollo: El marco de ingeniería segura de IBM | IBM Redbooks. 30 de septiembre de 2016.
  75. ^ Arquitectura de seguridad empresarial con soluciones de seguridad IBM Tivoli | IBM Redbooks. 30 de septiembre de 2016.
  76. ^ "Definiciones de diseño de arquitectura segura | CISA". us-cert.cisa.gov . Consultado el 9 de marzo de 2021 .
  77. ^ "Fundación OWASP | Fundación de código abierto para la seguridad de aplicaciones". owasp.org . Consultado el 24 de febrero de 2021 .
  78. ^ "Los 25 mejores de CWE". Sans.org . Consultado el 18 de octubre de 2013 .
  79. ^ IfSQ Nivel 2 Un estándar de nivel básico para el código fuente de programas informáticos Archivado el 27 de octubre de 2011 en Wayback Machine , segunda edición, agosto de 2008, Graham Bolton, Stuart Johnston, IfSQ, Instituto para la Calidad del Software.
  80. ^ 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 .
  81. ^ "Calidad del código: una preocupación para las empresas, los resultados y los programadores empáticos". Stack Overflow . 2021-10-18 . Consultado el 2023-12-05 .
  82. ^ Prause, Christian; Durdik, Zoya (3 de junio de 2012). "Diseño arquitectónico y documentación: ¿Desperdicio en el desarrollo ágil?". Conferencia internacional sobre software y procesos de sistemas (ICSSP) de 2012. IEEE Computer Society. págs. 130–134. doi :10.1109/ICSSP.2012.6225956. ISBN . 978-1-4673-2352-9.S2CID15216552  .​
  83. ^ "Estándares de dimensionamiento de software | CISQ - Consorcio para la información y la calidad del software". www.it-cisq.org . Consultado el 28 de enero de 2021 .
  84. ^ "Por qué falla el software". IEEE Spectrum: Noticias sobre tecnología, ingeniería y ciencia . 2 de septiembre de 2005. Consultado el 20 de marzo de 2021 .
  85. ^ Wagner, Stefan; Goeb, Andreas; Heinemann, Lars; Kläs, Michael; Lampasona, Constanza; Lochmann, Klaus; Mayr, Alois; Plösch, Reinhold; Seidl, Andreas (2015). "Modelos operacionalizados de calidad de productos y evaluación: el enfoque 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.
  86. ^ Suryanarayana, Girish (2015). "Proceso de software versus calidad de diseño: ¿un tira y afloja?". IEEE Software . 32 (4): 7–11. doi : 10.1109/MS.2015.87 . S2CID  9226051.
  87. ^ "Software Quality Professional | ASQ". asq.org . Consultado el 28 de enero de 2021 .
  88. ^ "Software Quality Journal". Springer . Consultado el 28 de enero de 2021 .

Bibliografía

Enlaces externos

Wikimedia Commons tiene medios relacionados con Calidad del software .