Calidad de software

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.

Calidad[editar]

  • Es la aptitud de un producto o servicio para satisfacer las necesidades del usuario.
  • Es la cualidad de todos los productos, no solamente de equipos sino también de programas.

En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.

Calidad de software[editar]

Características propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla. El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.

La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrás debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene entre 50 y 30 años de haber surgido.

El software necesita ser actualizado.

Certificación del software[editar]

Consecuencia de un proceso que es asegurar la calidad pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI, Moprosoft, etc.).

Normativa ISO 9000[editar]

Pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, audita el sistema. Si los resultados son positivos se emite la certificación y cada cierto tiempo se tiene que renovar. La certificación es costosa, a consecuencia de costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses). Se certifica la empresa y la metodología para el desarrollo de la aplicación.

Medición del software[editar]

En el software lo que se mide son atributos propios del mismo, se descompone un atributo general en otros más simples de medir, a veces se mide bien o mal ya que la descomposición del atributo genérico de calidad en otros sub-atributos se torna irreal, se mide con datos estadísticos no avalados, es imposible decir que la medición se hace en forma correcta.

El concepto de medida va de más a menos, va de lo general a lo concreto y lo concreto es asociado a la métrica, cuya combinación te daría el nivel de calidad o seguridad de tu producto. Las ciencias bien estructuradas se basan en medidas bien hechas, se basan en la matemática.

Tipos de medidas[editar]

  • Número de errores durante un periodo determinado.
  • Fallo en la codificación o diseño de un sistema que causa que el programa no funcione correctamente o falle.
  • Tamaño de un producto informático (líneas de código)
  • Estimación de costes y esfuerzos.

Utilidad de la medida del software[editar]

  • Normativa ISO 9126, medida de la calidad de software descomponiendo atributos, para no tener márgenes de error e interpretación.
  • Atributo de funcionalidad.
  • Atributo de capacidad de respuesta frente a errores externos.
  • Atributo de nivel de seguridad. La calidad no puede existir sin seguridad, un producto sin seguridad seria un producto sin calidad. El observador o usuario final indica que atributos más o menos importantes de seguridad.

Tipos de pruebas funcionales para mejorar la calidad del software[editar]

Tests unitarios[editar]

Esta es una tarea normalmente en exclusiva de los desarrolladores. Pero sin ella los bugs se propagan como una plaga.

Los tests unitarios son la primera barrera de control contra posibles bugs. Son la base del test driven development, si se quisiera seguir ese proceso. Agilizan el trabajo al poder cambiar partes del código y comprobar los fallos rápidamente. Son ejemplos para los nuevos desarrolladores que se añadan al proyecto.

Algunas ideas contrarias a los tests unitarios se basan en que un buen diseño o una buena planificación arregla muchos más problemas que los detectados por este tipo de tests. Aunque el diseño sea fantástico no puedes asegurar que el código funciona sin estos tests y dependerías de otras pruebas a más alto nivel.

Tests de integración[editar]

Los tests de integración son los que verdaderamente comprueban que el sistema está funcionando. Unen partes del sistema y comprueban que encajan sin problemas. Son la base del behaviour driven development, junto con los tests funcionales. Los tests unitarios no tienen en cuenta elementos tan importantes como los accesos a base de datos o peticiones de red. No son suficiente para comprobar que el comportamiento es correcto.

Gracias a este tipo de tests podemos encontrar bugs directamente en los pull requests sin necesidad de pasar regresivos relacionados con esa parte del producto. Hacen que el sistema sea fiable, pudiendo confiar en las partes protegidas por estos tests, ya que tendrán el comportamiento deseado al ser llamados por otros componentes. Protegen a los grupos de desarrolladores para que el código de otros componentes no les sorprenda de formas desagradables.

Al utilizar un lenguaje como gherkin para escribir este tipo de pruebas se consigue además una documentación extra sobre el funcionamiento del sistema. Pudiendo saber rápidamente qué está cubierto por los tests y qué no.

Tests funcionales[editar]

Es un paso más allá de los tests de integración y tratan de probar el sistema como lo haría un usuario. Aquí entra especialmente la automatización de interfaces gráficas. Son las pruebas funcionales que más mantenimiento necesitan y las más lentas.

Sin embargo los beneficios son similares a los anteriores tipos de pruebas. Protegen contra interfaces fallidas, quitan trabajo a la hora de hacer pruebas manuales. Son especialmente útiles al configurarlos y prepararlos para ser ejecutados en todos los entornos en los que se distribuye o se ejecuta la aplicación. Por ejemplo en los diferentes navegadores soportados, si la interfaz a probar fuera un entorno web.

Sin este tipo de tests estamos condenados a probar manualmente las interfaces, pudiendo dejarnos en el tintero posibles combinaciones. Suelen ser los mejores para las pequeñas suites de smoke tests.

Conclusión[editar]

No se puede medir la calidad del software de forma correcta debido a su naturaleza, la certificación se da a los procesos, la correcta consecución de los mismos garantizaría un buen software. No se puede medir al software como tal, sino los atributos que la conforman, tales métodos de medida deben ser exactos.

El usuario final mide la calidad del software según lo que tenga o no, es en ese sentido que la calidad del software depende de quien la juzgue. El hecho de que una empresa tenga certificación en calidad de software no garantiza que su software sea de calidad.

Enlaces externos[editar]