Calidad del software - Software quality

En el contexto de la ingeniería de software , la calidad del software se refiere a dos nociones relacionadas pero distintas:

• La calidad funcional del software refleja qué tan bien cumple o se ajusta a un diseño determinado, según los requisitos o especificaciones funcionales. Ese atributo también se puede describir 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 . 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 a través del análisis de la estructura interna del software, su código fuente (ver Métricas de software ), a nivel de unidad, nivel de sistema (a veces denominado prueba de extremo a extremo), que es en efecto, cómo su arquitectura se adhiere a los principios sólidos de la arquitectura de software descritos en un artículo sobre el tema de Object Management Group (OMG).

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

La calidad funcional se evalúa normalmente de forma dinámica, pero también es posible utilizar pruebas estáticas (como revisiones de software ).

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 . Con base en estos modelos (ver Modelos), el Consortium for IT Software Quality (CISQ) ha definido cinco características estructurales deseables principales necesarias para que una pieza de software proporcione valor comercial : confiabilidad, eficiencia, seguridad, mantenibilidad y tamaño (adecuado).

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. Dichos errores de programación encontrados 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.

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".

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 los procesos de parche ) y la gestión de la configuración son partes importantes de un proceso general de ingeniería de software.

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 han variado desde interfaces de usuario mal diseñadas hasta errores directos de programación , ver, por ejemplo, el caso del Boeing 737 o los casos de aceleración no intencionada o los casos Therac-25 . 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 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 tareas basura recopilan y actualizan la interfaz de usuario, y visualizan aviones cayendo del cielo ". 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 (un "producto" es un avión, un motor o una hélice). Los estándares 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. Los datos de la industria demuestran que la calidad estructural de la aplicación deficiente en las aplicaciones comerciales centrales (como la planificación de recursos empresariales (ERP), la gestión de relaciones con el cliente (CRM) o los grandes sistemas de procesamiento de transacciones en los servicios financieros) genera costos, sobrecostos en el cronograma y genera desperdicios en forma de retrabajo (ver Muda (término japonés) ). Además, la mala calidad estructural está fuertemente correlacionada con interrupciones comerciales de alto impacto debido a datos corruptos, interrupciones de las aplicaciones, brechas de seguridad y problemas de rendimiento.
  • CISQ informa sobre el costo de la mala calidad estima un impacto de:
    • $ 2.08 billones en 2020
    • $ 2,84 billones en 2018
  • El informe Costo de una violación de datos de IBM 2020 estima que los costos globales promedio de una violación de datos:
    • $ 3,86 millones

Definiciones

YO ASI

La calidad del software es la "capacidad de un producto de software para cumplir con los requisitos". mientras que para otros puede ser sinónimo de creación de valor o de cliente o incluso nivel de defecto.

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.

NIST

Software Assurance (SA) cubre tanto la propiedad como el proceso para lograrlo:

• 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 garantizar que se sigan esos procesos (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".

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 ".

Kitchenham y Pfleeger, que informan además sobre las enseñanzas de David Garvin, identifican cinco perspectivas diferentes sobre la calidad:

• 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 que nunca lo implementamos por completo". Difícilmente se puede definir, pero es similar a lo que una vez comentó un juez federal sobre la obscenidad: "Lo sé cuando lo veo".
• 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.
• La perspectiva de fabricación representa la calidad como conformidad con los requisitos. Este aspecto de la calidad se enfatiza 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).
• 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. 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.

-  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.

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".

Tom DeMarco ha propuesto que "la calidad de un producto es una función de cuánto cambia el mundo para mejor". 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". Esta definición enfatiza que la calidad es intrínsecamente 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" 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 a menudo se confunde con la garantía de calidad o la gestión de resolución de problemas o el control de calidad o DevOps . Se superpone con las áreas mencionadas anteriormente (consulte 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.

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 ]. 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 tienen solo un 35% de eficiencia. Esto dificulta la determinación de la calidad [del software].

Introducción

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.

Análisis basado en código

Muchas de las medidas de software existentes cuentan los elementos estructurales de la aplicación que resultan del análisis del código fuente para tales instrucciones individuales, tokens, estructuras de control ( complejidad ) y objetos.

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 vista 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 que hacen que un sistema determinado no sea adecuado para su uso. independientemente de su calificación basada en mediciones agregadas. Un ejemplo bien conocido de vulnerabilidad es Common Weakness Enumeration , un repositorio 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, la codificación y la documentación en línea de la aplicación, 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 de TRW (Boehm, 1978) 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 suelen realizar 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:

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 a menudo se encuentran 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 ( mejores prácticas de codificación )

Seguridad

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

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.
• Prácticas seguras de arquitectura de aplicaciones
• 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.)
• Prácticas de programación seguras y buenas
• 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 el código limpio y fácil de leer y el código desorganizado y difícil de leer. .

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

La mantenibilidad está estrechamente relacionada con el concepto de deuda técnica de Ward Cunningham , que es una expresión de los costos resultantes de la falta de mantenibilidad. Las razones por las que la mantenibilidad es baja pueden clasificarse como imprudentes frente a prudentes y deliberadas frente a inadvertidas, 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, código fuente mantenible .

Tamaño

La medición del tamaño del software requiere que todo el código fuente se recopile correctamente, incluidos los scripts de la 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 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.

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 a largo plazo.

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 nuevas propuestas de modelos de calidad como Squale y Quamoco 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 abstractos y complejos (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".
• " Lo sé cuando lo veo ".
• "No se puede controlar lo que no se puede medir". ( Tom DeMarco )
• "No se puede inspeccionar la calidad de un producto". ( W. Edwards Deming )
• "La amargura de la mala calidad permanece mucho después de que se haya olvidado la dulzura de cumplir con el cronograma". (Anónimo)
• "Si no comienza con una especificación, cada fragmento de código que escribe es un parche". ( Leslie Lamport )

Ver también

Otras lecturas

• Directrices de calidad del sistema operativo Android, incluidas listas de verificación para la interfaz de usuario, la seguridad, etc. Julio de 2021
• 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
• 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
• Laboratorio CAT - Laboratorio de herramientas de análisis de código CNES (en GitHub)
• Girish Suryanarayana, Proceso de software versus calidad de diseño: ¿Tira y afloja?
• 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.
• 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 del producto de software: la serie ISO 25000 y CMMI (sitio SEI)
• MSQF: un marco de calidad de software basado en mediciones Biblioteca de la Universidad de Cornell
• 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
• Software Quality Professional, Sociedad Estadounidense para la Calidad (ASQ)
• Revista de calidad de software 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.

Referencias

Notas

Bibliografía

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