DESARROLLO AGIL DE SOFTWARE

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:
o Funcionalidad entregada. Proporciona una medida indirecta de la
funcionalidad que se empaqueta con el software.
o 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.
o 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:
o Métricas arquitectónicas. Proporcionan un indicio de la calidad del diseño
arquitectónico.
o Métricas al nivel de componente. Mide la complejidad de los componentes
del software y otras características que impactan la calidad.
o Métricas de diseño de la interfaz. Se concentran principalmente en la
facilidad de uso.
o 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:
o Métricas de complejidad. Miden la complejidad lógica del código fuente.
o 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:
o Métricas de cobertura de instrucciones y ramas. Lleva al diseño de casos
de prueba que proporcionan cobertura del programa.
o Métricas relacionadas con los defectos. Se concentran en encontrar
defectos y no en las propias pruebas.
o Efectividad de la prueba. Proporciona un indicio en tiempo real de la
efectividad y de las pruebas aplicadas.
o 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.
FUENTE: https://www.eumed.net/tesis-doctorales/2014/jlcv/calidad-software.htm