2.12 Calidad en el desarrollo de software

Actualmente existe un gran interés por la calidad de los productos o servicios. En el mercado actual que es tan competitivo no basta con producir y distribuir los productos o servicios, vender es lo importante y esto se genera con la aceptación por parte del cliente, se dice que la calidad no tiene un concepto solo se reconoce. Sin embargo la calidad en el software es un concepto complejo que no es directamente comparable con la calidad de un producto. El software se ha convertido en la actualidad en uno de los principales objetivos estratégicos de las organizaciones debido a que, cada día, los procesos mas importantes de las organizaciones y su supervivencia dependen del funcionamiento del software.

Según Pressman (2005), es la concordancia del software producido con los requerimientos explícitamente establecidos y con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente, que desea el usuario.  Otra definición que contempla Vega, Rivera & García (2008) en su libro. Y que es propuesta por la organización internacional de estándares (ISO/IEC DEC 9126): “La totalidad de características de un producto de software que tienen como habilidad, satisfacer necesidades explícitas o implícitas”.
La calidad del software se puede observar en una característica o atributo. Como un atributo, la calidad se refiere a características mensurables, es decir cosas que se pueden comparar para conocer estándares, como longitud, color, propiedades eléctricas y maleabilidad. Sin embargo, el software que es una entidad intelectual, tiene la complejidad de caracterizar los objetos físicos. No obstante, existen mediciones que nos permiten evaluar las características de un programa. Dichas propiedades incluyen complejidad psicosomática, número de puntos de función, líneas de código, etcétera. Cuando se examina un elemento  sus características mensurables se pueden encontrar dos tipos de calidad:

• Calidad de diseño; la calidad de diseño se refiere a las características que los diseñadores especifican para un elemento.
• Calidad de concordancia; la calidad de concordancia es el grado en el que las especificaciones de diseño se aplican durante la fabricación.

En el desarrollo de software la calidad del diseño incluye requisitos, especificaciones y el diseño del sistema. La calidad de concordancia es un tema enfocado principalmente a la implementación. Si el diseño y el sistema resultante satisfacen los requisitos y metas de desempeño, la calidad de concordancia es alta. Glass (1998), argumenta que es conveniente generar una relación más intuitiva.
Satisfacción del usuario = producto manejable + buena calidad + entrega dentro del presupuesto y tiempo.

Glass (1998), afirma que la calidad es importante, pero si el usuario no está satisfecho, nada más importa en realidad. De igual forma afirma que la calidad de un producto es una función de cuánto cambia el mundo para mejorar. Esta visión de la calidad afirma que si un software proporciona beneficio sustancial a sus usuarios finales, éstos están dispuestos a tolerar problemas ocasionales en aspectos como la confiabilidad y el desempeño.

• Control de calidad.

El control de la variación puede equipararse con el control de calidad. Esto involucra la serie de inspecciones, revisiones y pruebas empleadas a lo largo del proceso del software para garantizar que cada producto del trabajo satisfaga los requisitos que se le han asignado. El control de calidad incluye un bucle de retroalimentación con el proceso que creó el producto del trabajo. La combinación de mediciones retroalimentación permite afinar el proceso cuando los productos de trabajo creados fracasan en cuanto a satisfacer sus especificaciones. Un concepto clave del control de calidad es que todos los productos de trabajo tienen especificaciones definidas mensurables con las cuales se puede comparar la salida de cada proceso. Dicho bucle es esencial para minimizar los efectos producidos.

• Garantía de la calidad.

La garantía de la calidad consiste en un conjunto de funciones de auditoría e información que evalúan la efectividad y qué tan completa son las actividades de control de calidad. La meta del aseguramiento de la calidad es presentarle al gestor los datos necesarios para que esté informado acerca de la calidad del producto y por consiguiente que comprenda y confíe en que la calidad del producto está satisfaciendo las metas y objetivos. Si se identifican problemas en el proceso de aseguramiento de calidad, es responsabilidad del gestor aportarlos y aplicar los recursos necesarios para resolver los conflictos de calidad.

• Costo de la calidad.

El costo de la calidad incluye todos los costos que se generan o que demandan el desarrollo de las actividades relacionadas con la calidad. Los estudios de costo de la calidad se llevan a cabo para ofrecer una línea base e identificar oportunidades que reduzcan el costo de calidad y proporcionan una base que sirva de comparación. La base de normalización casi siempre es monetaria, ya que se tienen los datos necesarios para evaluar dónde se encuentran las oportunidades para mejorar los procesos, se puede evaluar el efecto de los cambios en términos monetarios. Los costos de calidad se dividen en:
1) Costos asociados con prevención; estos costos incluyen la planificación de la calidad, revisiones técnicas formales, equipo de pruebas y entrenamiento.
2) Evaluación y fallas; estos costos incluyen actividades que permiten comprender mejor la condición del producto a través de cada proceso. Algunos ejemplos de costos de valuación incluye ni inspección en el proceso y procesos, calibración y mantenimiento de equipo además de las pruebas correspondientes. Los costos de fallas son aquellos que desaparecerán si no hubiese defectos antes de enviar el producto a los clientes. Estos costos se subdividen en costos de fallas internas y externas.

Se incurren los costos de fallas internas cuando se detecta un defecto en el producto antes del envío, dichos costos incluyen reelaboración, reparación y análisis el modo de falla. Los costos de fallas externas se asocian con defectos detectados después de que el producto ha sido enviado al cliente algunos ejemplos de estos son la resolución de las quejas, devolución y reemplazo del producto, soporte de ayuda en línea y trabajo de garantía.

• Garantía de la calidad del software.

El control y la garantía de la calidad son actividades esenciales en cualquier negocio que elabora productos de consumo. En la actualidad,  toda compañía tiene mecanismos que garantizan la calidad en sus productos. De hecho, las afirmaciones explícitas de la preocupación de una compañía por la calidad se ha convertido en una práctica de mercadotecnia durante las décadas pasadas. La historia de la garantía de la calidad en el desarrollo de software avanza paralelamente a la de la calidad en la fabricación del hardware. Durante los primeros días de la computación (décadas de 1950 y 1960), la calidad era responsabilidad exclusiva del programado. Los estándares de garantía de la calidad para el software se introdujeron en los contratos militares durante el decenio de 1970 y se han extendido rápidamente en el desarrollo del software en el mundo de los negocios.

Si se extiende la definición de garantía de la calidad del software podemos decir que es un patrón de acciones sistemático y planificado que se requiere para garantizar la alta calidad en el software. Numerosos y diversos participantes tienen responsabilidad en la garantía de la calidad del software como ingenieros de software, gestores del proyecto, clientes, vendedores y los individuos que participan en el grupo de desarrollo. Las revisiones del software son un filtro para el proceso de software. Esto es, que las revisiones se aplican en varios puntos durante la ingeniería del software y sirven para descubrir errores y defectos que pueden eliminarse. La revisiones del software purifican las actividades que se han denominado análisis, diseño y codificación. Freedman & Weinberg (1990), abordan el modo siguiente y la necesidad de la revisiones:
" el trabajo técnico necesita revisarse por la misma razón que los lápices necesitan gomas, errar es de humanos. La segunda razón por la que se necesitan las revisiones técnicas es que aunque la gente sea buena al captar algunos de sus propios errores, las grandes clases de errores escapan de su creador con más facilidad de lo que se le escapan a alguien más".

El objetivo principal de las revisiones técnicas formales es descubrir los errores durante el proceso, de modo que no se conviertan en defectos después de liberar el software. El beneficio de las revisiones técnicas formales es el descubrimiento temprano de los errores de modo que ya no se propaguen a la etapa siguiente en el proceso de desarrollo de software.
De acuerdo a los estudios realizados por Vega et al (2008), algunas normativas de calidad en los sistemas de información y que ayudan a la realización, además de  aplicar mejores prácticas en las organizaciones son:

• ISO 9000, gestión y aseguramiento de calidad (conceptos y directrices generales).
• Recomendaciones externas para aseguramiento de la calidad (ISO 9001, ISO 9002, ISO 9003).
• Recomendaciones externas internas para aseguramiento de la calidad (ISO 9004).
• Malcom Baldridge national quality award.
• Software Engineering Institute (SEI).
• Capability Maturity Model (CMM).
• Six Sigma.

Los sistemas ISO de garantía de calidad fueron creados para ayudar a las organizaciones a garantizar que sus productos y servicios satisfacen las expectativas de los clientes al cumplir las especificaciones. El estándar ISO 9000 describe un sistema que garantiza la calidad en términos genéricos y que se puede aplicar a cualquier negocio sin importar los productos o servicios ofrecidos. ISO 9000 requiere que los sistemas de operaciones de calidad y una compañía se sometan a revisión de auditores de una tercera entidad, el cual tiene conocimiento del estándar y de su funcionamiento. Antes del registro exitoso, los auditores extienden a la compañía un certificado de la organización que representan. Entrevistas de auditoría semianuales garantizan la concordancia continua con el estándar.

El estándar de garantía de la calidad que se aplica en la ingeniería del software es el ISO 9001: 2000. Este estándar contiene 20 requisitos que deben estar presentes para generar un sistema eficiente de garantía de la calidad. Puesto que el estándar 9001: 2000 es aplicable a todas las disciplinas de ingeniería, se ha desarrollado un conjunto especial de directrices que permiten interpretar el estándar para emplearlo en el proceso de software. Los requisitos que especifica el estándar abordan tópicos como responsabilidad de la gestión, sistema de calidad, revisión de contrato, control de diseño, control de documentos y datos, identificación y seguimiento del producto, control de proceso, inspección y pruebas, acciones correctivas y preventivas, control de registros de calidad, auditorías de calidad interna, entrenamiento, servicio y técnicas estadísticas.

Una organización de software obtendrá el registro ISO 9001:2000 si establece políticas y procedimientos para abordar cada uno de los requisitos anotados además, ser capaz de demostrar que se siguen dichas políticas y procedimientos.
Entre las políticas y procedimientos que se deben de demostrar en una auditoría están las siguientes:
a) Establecer los elementos de un sistema de gestión de calidad

• Desarrollar, implementar y mejorar el sistema.
• Definir una política enfatice la importancia del sistema.

b) Documentar el sistema de calidad

• Describir el proceso.
• Producir un manual operativo.
• Desarrollar métodos para controlar los documentos.
• Establecer métodos para la conservación de registros.

c) Soporte del control y la garantía de calidad

• Promover la importancia de la calidad entre todos los participantes.
• Enfocarse en la satisfacción del cliente.
• Definir un plan de calidad que aborde objetivos, responsabilidades de autoridad.
• Definir mecanismos de comunicación entre los participantes.

d) Establecer mecanismos de revisión para el sistema de gestión de calidad

• Identificar métodos de revisión y mecanismos de retroalimentación.
• Definir procedimientos de seguimiento.
• Identificar recursos de calidad que incluyan personal, entrenamiento, elementos de infraestructura.

e) Establecer mecanismos de control

• Para planeación.
• Para requisitos del cliente.
• Para actividades técnicas, por ejemplo análisis diseño y pruebas.
• Para supervisión y gestión del proyecto.

f) Definir métodos para corrección

• Valorar los datos y métricas de calidad.
• Definir enfoques para procesos continuos y de mejora de la calidad.

Según Dunn y Ullman(1982), "el aseguramiento de la calidad del software es el mapeo de los preceptos gerenciales y las disciplinas de diseño de la garantía de calidad en el espacio gerencial y tecnológico aplicable del ingeniería del software".
La habilidad para garantizar la calidad es la medida de una disciplina de ingeniería madura. Cuando el mapeo se logra de manera exitosa el resultado es la aplicación de la ingeniería de software en un nivel de madurez.

2.12.1 Elementos que permiten evaluar la calidad en el software

Según Juran (1992), la calidad, para poder ser entendida de una mejor manera y posteriormente ser medida con eficacia, debe ser expresada por medio de otros términos que tengan más sentido para el usuario. En el caso del software. Estos factores son el medio por el cual se traduce el término “calidad” al lenguaje de las personas que manejan la tecnología.
Los factores de calidad que afectan a la calidad del software se dividen en dos grandes grupos:

• Los que miden directamente (defectos descubiertos en las pruebas).
• Los que se miden directamente (facilidad de uso o de mantenimiento).

En cada caso debe presentarse una medición. Se debe comparar el software con algún conjunto de datos y obtener así algún indicio sobre la calidad. McCall, Richards & Walters (1977), propusieron una clasificación de los factores que afectan directamente a la calidad del software. Estos factores se muestran en la figura 2.30 En ella se concentran tres aspectos importantes de un software:

• Características operativas.
• Capacidad para experimentar cambios.
• Capacidad para adaptarse a nuevos entornos.

A continuación se describen los factores que propone McCall, Richards & Walters.

• Corrección.

El grado en que el programa cumple con su especificación y satisfacer los objetivos que propuso el cliente.

• Confiabilidad.

El grado en que se esperaría que un programa desempeña su función con la precisión requerida.

• Eficiencia.

La cantidad de código y de recursos de cómputo necesarios para que un programa realice su función.

• Integridad.

El grado de control sobre el acceso al software o los datos por parte de las personas no autorizadas.

• Facilidad de uso.

El esfuerzo necesario para aprender, operar y preparar los datos de entrada de un programa interpretan la salida.

• Facilidad de mantenimiento.

El esfuerzo necesario para localizar y corregir un error en un programa.

• Flexibilidad.

El esfuerzo que demanda probar un programa con el fin de asegurar que realiza su función.

• Portabilidad.

El esfuerzo necesario para transferir el programa de un entorno de hardware o software a otro.

• Facilidad de reutilización.

El grado en que un programa o partes de él pueden reutilizarse en otras aplicaciones(en relación con el empaquetamiento y el alcance de las funciones que realiza el programa).

• Interoperabilidad.

El esfuerzo necesario para acoplar un sistema con otro.

Es difícil y en algunos casos imposible, desarrollar medidas directas 1 de estos factores de la calidad. En realidad, muchas de las métricas que definen McCall et al. Sólo se miden de forma subjetiva. Ya que es común que las métricas adquieran la forma de una lista de comprobación que se emplea para “asignar una graduación” a atributos específicos del software. Vega et al. (2008), proponen un modelo con métricas distintas al propuesto por McCall y que ha sido utilizado y comprobado en distintos proyectos de desarrollo de software. Los factores que conforman al modelo y su descripción, se presentan a continuación.

• Corrección.

El grado en que un producto de software satisface sus especificaciones y consigue los objetivos de la misión encomendada por el usuario.

• Confiabilidad.

El grado en que se puede esperar que un producto de software lleve a cabo sus funciones esperadas con la precisión requerida.

• Eficiencia.

La cantidad de recursos computacionales y de código requeridos por un producto de software para llevar a cabo las funciones encomendadas.

• Integridad.

El grado en que puede controlarse (facilitar y restringir) el uso y acceso al software y a los datos, tanto al personal autorizado como al no autorizado.

• Facilidad de uso.

El esfuerzo requerido para aprender, trabajar, preparar la entrada e interpretar la salida de un producto de software.

• Facilidad de mantenimiento.

El esfuerzo necesario para localizar y corregir los errores en un producto de software.

• Flexibilidad.

El esfuerzo requerido para modificar un producto de software una vez que se encuentra ya liberado o en producción, esto es, una vez que el usuario esté haciendo uso de él.

• Facilidad de prueba.

El esfuerzo requerido para probar un producto de software, de tal forma que se asegure que realiza las funciones especificadas por el usuario.

• Portabilidad.

El esfuerzo requerido para transferir un producto de software de una plataforma (entorno de hardware y software) a otra.

• Reusabilidad.

El grado en que un producto de software (o alguna de sus partes) pueda volver a ser utilizado en otras aplicaciones, aún cuando la funcionalidad de la misma cambie.

• Facilidad de interoperación.

El esfuerzo requerido para lograr que un producto de software trabaje con otro, compartiendo recursos.

2.12.2 Medidas, métricas e indicadores

La medición asigna números o símbolos a atributos de entidades reales. Esto requiere un modelo de medición que abarque un conjunto existente de reglas. En el contexto de la ingeniería del software una medida proporciona una indicación cuantitativa de la extensión, la cantidad, la dimensión, la capacidad o el tamaño de algún atributo de un producto o proceso. La medición ocurre como resultado de la recopilación de uno o más puntos de datos. Una métrica de software relaciona de alguna manera las medidas individuales, de igual manera un ingeniero de software recopila medidas y desarrolla métricas para obtener los indicadores.

Un indicador es una métrica o una combinación de métricas que proporcionan conocimientos acerca del proceso del desarrollo de software, un proyecto de software o el propio producto. Un indicador proporciona conocimientos que permiten a los ingenieros de software ajustar el proceso, el proyecto o el producto para que las cosas mejoren. Existe la necesidad de medir y controlar la complejidad en el desarrollo del software, debe de tenerse la posibilidad de desarrollar medidas de diferentes atributos internos del programa. Estas medidas y las métricas derivadas de ellas se utilizan como indicadores independientes de la calidad de los modelos de análisis y diseño.

Antes de generar e introducir una serie de métricas del producto debemos contemplar que se:

• Deben de ayudar a evaluar los modelos de análisis y diseño.
• Deben ofrecer una indicación de la complejidad de los diseños procedimentales y el código fuente.

3) Deben de facilitar el diseño de pruebas más efectivas.

Es importante comprender los principios básicos de la medición. Según Roche (1994), sugiere un proceso de medición en el que se caracterizan cinco actividades primordiales las cuales son:
1) Formulación. La derivación de medidas  y métricas apropiadas para la representación del software que se considera.
2) Recolección. El mecanismo con que se acumulan los datos necesarios para derivar las métricas formuladas.
3) Análisis. El cálculo de las métricas y la aplicación de herramientas matemáticas.
4) Interpretación. La evaluación de las métricas en un esfuerzo por conocer mejor la calidad de la representación.
5) Retroalimentación. Recomendaciones derivadas de la interpretación de las métricas del producto transmitidas al equipo del software.

Las métricas del software sólo serán útiles si están caracterizadas de manera efectiva y se validan para probar su valor. Según Lethbridge (2003), los siguientes principios son representativos de muchos otros que podrían proponerse para caracterizar y validar las métricas. Una métrica debe tener propiedades matemáticas deseables. Es decir, el valor de la métrica debe estar en un rango significativo por ejemplo, de cero a uno, donde cero realmente significa ausencia, uno indica el valor máximo y 0.5 representa el punto medio. Además, una métrica pretende estar en una escala racional no debe contar con componentes que sólo se miden en una escala ordinal. Cuando una métrica representa una característica de software que aumenta cuando se presentan rasgos positivos o que disminuya al encontrar rasgos indeseables, el valor de la métrica debe aumentar o disminuir en el mismo sentido.

Cada métrica debe validarse empíricamente en una amplia variedad de contextos antes de publicarse o aplicarse la toma de decisiones. Una métrica debe medir el factor de interés, independientemente de otros factores. Debe crecer para aplicarse a sistemas grandes y funcionar en diversos lenguajes de programación y dominios de sistemas. Aunque la formulación, caracterización y validación son críticas, la recopilación y el análisis son las actividades que dirigen el proceso de medición. Roche(1994) sugiere las siguientes directrices para estas actividades:
1) Siempre que sea posible deben automatizarse la recopilación de datos y su análisis.
2) Deben aplicarse técnicas estadísticas válidas para establecer relaciones entre los atributos internos del producto y las características externas de la calidad.
3) Para cada métrica deben establecerse directrices y recomendaciones para la interpretación.

Se han propuesto cientos de métricas para el desarrollo de software pero no todas proporcionan un soporte práctico para el ingeniero de software. Algunas exigen mediciones demasiado complejas otras son demasiado especializadas que pocos profesionales podrían comprenderlas y otras más violan las nociones básicas de lo que es el software de alta calidad. Ejiogu (1991), define un conjunto de atributos que toda métrica efectiva del software debe abarcar. La métrica derivada y las medidas que llevan a ella deben ser:

• Simples incalculables. Debe ser relativamente fácil aprender a derivar la métrica y su cálculo no debe exigir cantidades anormales de tiempo o esfuerzo.
• Empírica e intuitivamente persuasivas. La métrica debe satisfacer las nociones intuitivas del ingeniero acerca del atributo del producto que se está construyendo.
• Consistentes y objetivas. La métrica siempre debe arrojar resultados que no permitan ambigüedad alguna.
• Consistentes en el uso de unidades y dimensiones. El cálculo matemático de la métrica debe emplear medidas que no lleven a combinaciones extrañas de unidades.
• Independientes del lenguaje de programación. Las métricas deben basarse en el modelo de análisis o diseño o en la estructura del propio programa.
• Mecanismos efectivos para la retroalimentación de alta calidad. Es decir, la métrica debe llevar a un producto final de la más alta calidad.

Aunque casi todas las métricas de software satisfacen esos atributos, algunas métricas de uso común no cumplen con una o dos de ellas. Aunque se ha propuesto una amplia variedad de taxonomía en métricas, el siguiente esquema atiende a las cuatro más importantes en el desarrollo del software.

• Métricas para el modelo de análisis. Estas métricas atienden varios aspectos de la etapa de análisis en donde se incluyen:
• Funcionalidad entregada. Proporciona una medida indirecta de la funcionalidad que se empaqueta con el software.
• Tamaño del sistema. Mide el tamaño general del sistema, definido desde el punto de vista de la información disponible como parte del modelo de análisis.
• Calidad de la especificación. Proporciona un indicador específico o el grado en que se ha completado la especificación de los requisitos.
• Métricas para el modelo de diseño. Estas métricas cuantifican los atributos del diseño de manera tal que le permiten al ingeniero de software evaluar la calidad del diseño, la métrica incluye:
• Métricas arquitectónicas. Proporcionan un indicio de la calidad del diseño arquitectónico.
• Métricas al nivel de componente. Mide la complejidad de los componentes del software y otras características que impactan la calidad.
• Métricas de diseño de la interfaz. Se concentran principalmente en la facilidad de uso.
• Métricas especializadas en diseño orientado a objetos. Miden características de clases, además de las correspondientes a comunicación y colaboración.

• Métricas para el código fuente. Estas métricas miden el código fuente y se usan para evaluar su complejidad, además de la facilidad con que se mantiene y prueba entre otras características como:
• Métricas de complejidad. Miden la complejidad lógica del código fuente.
• Métricas de longitud. Proporcionan un indicio del tamaño del software.
• Métricas para pruebas. Estas métricas ayudan a diseñar casos de prueba efectivos y evaluar la eficacia de las pruebas en donde se incluyen:
• Métricas de cobertura de instrucciones y ramas. Lleva al diseño de casos de prueba que proporcionan cobertura del programa.
• Métricas relacionadas con los defectos. Se concentran en encontrar defectos y no en las propias pruebas.
• Efectividad de la prueba. Proporciona un indicio en tiempo real de la efectividad y de las pruebas aplicadas.
• Métricas en el proceso. Métrica relacionadas con el proceso de las pruebas.

En muchos casos las métricas de un modelo pueden aplicarse en actividades posteriores de la ingeniería del software. Por ejemplo, las métricas de diseño se utilizan para estimar el esfuerzo requerido para generar código fuente.