Calidad en el Software

Dentro del contexto de Ingeniera de Software, se tomar la definicin de calidad

en el software propuesta por la organizacin internacional de estndares (ISO/IEC
DEC 9126) que dice la calidad del software es el cumplimiento de la totalidad de
caractersticas de un producto de software que tienen como habilidad, satisfacer
necesidades explcitas o implcitas.
Otra definicin bastante completa de calidad en el software es la que se presenta
a continuacin:
Se puede decir que el software tiene calidad si cumple o excede las expectativas
del usuario en cuanto a:
1. Funcionalidad (que sirva un propsito),
2. Ejecucin (que sea prctico),
3. Confiabilidad (que haga lo que debe),
4. Disponibilidad (que funcione bajo cualquier circunstancia) y
5. Apoyo, a un costo menor o igual al que el usuario est dispuesto a pagar.
Resumiendo podemos decir, que la calidad de software se refiere a: Los factores
de un producto de software que contribuyen a la satisfaccin completa y total de
las necesidades de un usuario u organizacin.
Aseguramiento de Calidad de Software (SQA)
La funcin de aseguramiento de la calidad tiene como finalidad primaria el
determinar si las necesidades de los usuarios estn siendo satisfechas
adecuadamente. Otra de sus funciones, es la de determinar los costos que puede
causar el aadir ciertas caractersticas al producto, ya que tarde o temprano, la
economa resulta ser un factor decisivo para obtener un producto de calidad. Para
determinar si las necesidades de los usuarios estn siendo satisfechas, se deben
de evaluar tres reas:
Objetivos: Los objetivos de la organizacin son primero, luego vienen los
requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en
armona con los objetivos de la organizacin.
Mtodos: Deben de utilizarse mtodos que contengan u observen las polticas,
procedimientos y estndares de la organizacin.
Ejecucin: Optimizacin del uso de hardware y software al implementar los
productos de software.
Para evaluar las reas expuestas con anterioridad, es necesario que se cuente
con un programa de aseguramiento de calidad que sea efectivo y que tenga un
impacto dentro del desarrollo y prueba del producto de software final.
Necesidad de la Calidad y de sus Procesos de Aseguramiento.
La calidad en el software es imprescindible. Las organizaciones de la actualidad
se encuentran en una situacin donde deben idear estrategias que las pongan en
ventaja con sus competidores y las tecnologas de informacin son herramientas
usualmente escogidas con este propsito. Las razones, que sustentan lo
anteriormente escrito, son:
La naturaleza crtica de algunas tareas realizadas por las computadoras. En
la actualidad se est dando una creciente dependencia de los sistemas
computacionales, donde alguna falla puede resultar en catstrofes personales
(sistemas de control areo, en los aeropuertos) y econmicas (sistemas
transaccionales en los bancos).
El crecimiento de los costos de desarrollo de productos de software. Los
costos causados por mantenimiento de software son cada vez mayores, por lo que
se vuelve indispensable evitar errores desde la definicin de requerimientos.

La competencia entre los desarrolladores de productos de software. Para
producir software de alta calidad, como un medio para ganar mercado.
Sin embargo, pese a que se conoce la necesidad de producir software de calidad,
la cultura actual de la calidad ensea que en las organizaciones los
administradores empiezan a involucrarse en los procesos de desarrollo de
tecnologa de informacin una vez que se han incurrido en costos de
mantenimiento, ya sean ocasionados por un mal diseo, o por no satisfacer los
requerimientos correctamente.
Beneficios de los procesos de Aseguramiento de la Calidad en el Software.
Los beneficios que se pueden obtener como resultado de aplicar los procesos de
aseguramiento de calidad son muchos y variados, algunos que se pueden citar
con brevedad son:
1. Se detectan problemas rpidamente, Es posible identificar problemas en
tempranas etapas del desarrollo de productos de software, ayudando al
desarrollador a corregirlos inmediatamente y poder avanzar con ms rapidez.

2. Se crean y se siguen estndares de trabajo, Con apoyo del proceso de
aseguramiento de calidad, se pueden establecer estndares tan diversos como
son los de codificacin o de documentacin, los cuales apoyan a uniformizar y
consolidar el proceso de desarrollo.
3. Se verifica que los objetivos individuales vayan acordes con los objetivos
de la organizacin, Se busca y se recomienda que los requerimientos expuestos
por usuarios finales estn alineados con los objetivos globales de la empresa,
facilitando as el logro de los mismos y la integracin total de los usuarios a la
organizacin.

4. Se recomiendan mtodos para realizar el trabajo, Las prcticas de
aseguramiento de calidad, como son muy robustas ya que aplican tcnicas muy
completas de medicin, pueden proponer en un momento dado qu mtodos se
ajustan ms a la naturaleza del producto a ser desarrollado, teniendo como efecto
final que el producto tenga ms posibilidades de ser un producto con calidad.

5. Se evita incurrir en costos innecesarios, Como un efecto generalizado de
algunos de los puntos mencionados con anterioridad, la prctica de procesos de
aseguramiento de calidad lleva a las organizaciones a evitar costos no deseados
como pueden ser todos aquellos ocasionados por mantenimiento correctivo.

6. Se planea la calidad, Est claro que el concepto de calidad no es algo que se
da de una manera automtica e impredeciblemente. Es algo que se busca. Por lo
mismo, se debe de planear, construir e implantar en el producto.
Mtricas de Software
Definicin: Una mtrica de software se refiere a aquella aplicacin continua de
tcnicas basadas en la medida de los procesos de desarrollo del software, para
producir una informacin de gestin significativa al mismo tiempo que se mejoran
aquellos procesos y sus productos.
Otra de las definiciones dice que una mtrica es: Un Mtodo y una escala
cuantitativos que pueden ser usados para determinar el valor que toma cierta
caracterstica en un producto de software concreto.
Tambin puede ser definida como: Una funcin que toma como entrada cierta
informacin del software que se est midiendo, y que devuelve como salida un
valor numrico sencillo, el cual es interpretada, como el grado en que el producto
de software posee un atributo dado que afecta a su calidad.
Caractersticas: Se afirma que para que las mtricas sean tiles ests deben
tener las siguientes cuatro caractersticas:
1. Cuantificables, deben basarse en hechos, no en opiniones.
2. Independientes, los recursos no deben poder ser alterados por los miembros
que las apliquen o utilicen.
3. Explicable, debe documentarse informacin acerca de la mtrica y de su uso.
4. Precisas, debe de conocerse un nivel de tolerancia permitido cuando se mide.
Mtricas del producto
Para justificar la existencia de este tipo de mtrica, se argumenta que stas deben
ser enunciadas y utilizadas para administrar el proceso de desarrollo y debe ser
conforme al producto de software particular. El proveedor de productos de
software debe de recopilar y actuar sobre las medidas cuantitativas de la calidad
de esos productos de software.
Estas medidas deben ser utilizadas para los siguientes propsitos:
1. Para recopilar informacin y reportar valores de mtricas sobre bases regulares.
2. Para identificar el actual nivel de desempeo por cada mtrica.
3. Para tomar la accin remedial si los niveles de las mtricas crecen peor o
exceden los niveles objetivos establecidos.
4. Para establecer metas de mejoras especificas en trminos de las mismas
mtricas.

Mtricas de proceso
El proveedor debe tener mtricas cuantitativas de la calidad del proceso de
desarrollo y de liberacin. Estas mtricas deben de reflejar:
a) Qu tan bien el proceso de desarrollo est siendo llevado a cabo en trminos
de puntos de revisin y en objetivos de calidad en el proceso, siendo cumplidos en
tiempo de calendario.
b) Qu tan efectivo es el proceso de desarrollo, al reducir la probabilidad que se
introduzcan fallas o que cualquier falla introducida sea detectada.
Aqu como las partes de las mtricas del producto, lo importante es que los niveles
sean conocidos y utilizados, para el control del proceso y de las mejoras, y no
sean utilizadas mtricas fijas. Las mtricas seleccionadas deben de ajustarse al
proceso utilizado y si es posible, tener un impacto directo sobre la calidad de
software liberado.
Las mtricas tambin pueden ser categorizadas como mtricas de resultado o
mtricas de prediccin. Una medicin de prediccin es normalmente una mtrica
de producto que puede ser utilizada para predecir el valor de otra mtrica. La
mtrica es predicha, una mtrica de proceso, es conocida como una mtrica de
resultado.
Uso de Mtricas
Las mtricas deben ser implantadas paso a paso en cinco niveles,
correspondientes al nivel de madurez del proceso de desarrollo.
Proceso Inicial (Nivel 1): Su objetivo es formar una base de comparacin con la
forma en que las mejoras se realicen y se incremente la madurez, estos incluyen:
a) El tamao del producto,
b) El esfuerzo del personal (Utilidades para determinar una tasa de productividad)

Proceso Repetible (Nivel 2): Las mtricas a este segundo nivel incluyen como
objetivos de medicin los siguientes:
1. La cantidad de esfuerzo necesaria para desarrollar un sistema,
2. La duracin del proyecto,
3. El tamao y la volatilidad de los requerimientos,
4. El costo global del proyecto (Por lo que el tipo de mtrica que se recomiendan
incluye a las siguientes):
a) Tamao del software (Lneas de codillo fuente no comentadas).
b) Puntos de Funcin.
c) Cuenta de objetos y mtodos.
5. Esfuerzo del trabajo de personal:
a) Esfuerzo real medido en unidades persona/mes.
b) Esfuerzo reportado en unidades persona/mes.
6. Volatilidad de los requerimientos (Cambios de los requerimientos).
stas se incluyen como mtricas principales para realizar la medicin.
Adems las siguientes pueden aadirse a consideracin de la administracin del
proyecto de software.
7. Experiencia (del dominio o aplicacin, de la arquitectura de desarrollo utilizada,
de las herramientas y mtodos empleados, aos globales de experiencia en el
desarrollo),
8. Rotacin de personal
Proceso definido (Nivel 3): En este nivel de madurez, se recomienda evaluar la
complejidad de los requerimientos, el diseo, el cdigo y los planes de prueba, y
evaluar la calidad de los requerimientos del diseo del cdigo y de las pruebas. En
trminos de complejidad, se sugiere que los siguientes puntos se midan a este
nivel:
1. Complejidad de los requerimientos (Nmero de distintos objetos y acciones
llevadas a cabo en los requerimientos).
2. Complejidad del Diseo (Nmero de mdulos de diseo, Complejidad
Ciclomtica, Complejidad de Diseo de McCabe.
3. Complejidad del Cdigo (Nmeros de Mdulos de Cdigo, Complejidad
Ciclomtica.
4. Complejidad de las pruebas (Nmero de Caminos a probar, Si el desarrollo es
orientado a objetos, debe de considerarse el nmero de interfaces de objetos a
probar. Se puede evaluar la minuciosidad de las pruebas. As, por mencionar
algunas mtricas recomendadas de calidad, podemos decir las siguientes:
a) Defectos descubiertos,
b) Defectos descubiertos por unidad de tamao (densidad de defectos),
c) Fallas de requerimientos descubiertos,
d) Fallas de diseo descubiertas,
e) Fallas de Cdigo descubiertas,
f) Densidad de fallas por cada producto.
Se enfatiza que este conjunto no es representativo del espectro completo de
medidas que pueden ser empleadas. Aspectos tales como facilidad de
mantenimientos, grado de utilizacin facilidad de uso y otros atributos de calidad
de software que no son considerados por la cuenta de defectos.
Proceso Administrado (Nivel 4): En este nivel la retroalimentacin determina
cmo son asignados los recursos pues las actividades bsicas por s mismas no
cambian. Las mtricas recolectadas son utilizadas para encontrar y estabilizar el
proceso, as la productividad y la calidad coinciden con las expectativas. Se
recomienda por lo tanto recolectar informacin al respecto de los siguientes
aspectos:

- Tipo de proceso, se refiere a qu tipo de modelo se utiliza para el desarrollo de
software.
- Cantidad de reuso del producto, este aspecto se relaciona con que tanto se
disea el software para su reuso.
- Cantidad de reuso del Consumidor, Este aspecto es establecido en
consideracin a cuanto reuso de los componentes de un proyecto y de otros
aspectos.
- Identificacin de defectos, se relaciona con cmo y cundo se descubren los
defectos.
- Uso de la densidad de defectos para las pruebas, se relaciona con la extensin
del nmero de defectos que determina cundo estn completas las pruebas.
- Uso de la administracin de la configuracin, cuestiona acerca de que si la
configuracin de la administracin es un esquema impuesto sobre el proceso de
desarrollo.
- Terminacin de mdulos sobre tiempo, considera en qu porcentaje los mdulos
estn siendo debidamente terminados.
Optimizacin del Proceso (Nivel 5): A este nivel las mtricas de las actividades
son utilizadas para mejorar el proceso.
Pruebas de Software
La definicin de pruebas en el contexto del software tiene diferentes
connotaciones que en algunos casos llevan a malas interpretaciones. La definicin
de pruebas de software de Myers es: Las pruebas son el proceso de ejecucin de
un programa con la intensin de encontrar errores; adems, sta es una parte
fundamental del aseguramiento de la calidad del software (QA, por sus siglas en
ingles), ya que ayuda a asegurar que el producto cumpla con los requisitos; sin
embargo las pruebas de software no son QA, tan solo son una parte de ella.
La industria del software a travs de su historia ha encontrado la necesidad de
refinar aspectos fundamentales vinculados directamente a su proceso productivo:
1. Los costos y el tiempo: la dificultad de planear proyectos de software trae
consigo problemas en la estimacin de tiempos y por ende altos costos asociados;
la creacin de mtricas de software y procesos de planeacin eficientes han
ayudado a amortiguar el peso de stos factores en el desarrollo del software.
2. La calidad: debido a la competitividad del mercado de software la calidad se
convierte en un factor determinante a la hora de comercializar los productos.
Igualmente, permite disminuir los tiempos de mantenimiento al obtener productos
con menor cantidad de errores inyectados y por ende ms confiables.
La importancia de las pruebas de software se puede visualizar teniendo como
referencia algunos autores:
- Las pruebas de software permiten pasar de forma confiable del cmodo
ambiente planteado por la ingeniera de software, es decir del controlado ambiente
de anlisis, diseo y construccin, al exigente mundo real en el cual los entornos
de produccin someten los productos a todo tipo de fatiga.
- Las pruebas de software basadas en componentes permite la reutilizacin y por
ende la reduccin de los ciclos de pruebas, lo cual se ve reflejado en la
disminucin de costos y tiempos.
- La necesidad de productos de software de alta calidad ha obligado a identificar y
cuantificar factores de calidad como: capacidad de uso, capacidad de prueba,
capacidad de mantenimiento, capacidad de ser medible, capacidad de ser
confiable y a desarrollar practicas de ingeniera que contribuyen a la obtencin de
productos de alta calidad.
Taxonoma de las Pruebas en aplicaciones de Software
Las pruebas de software se tipifican de acuerdo a los aspectos especficos que se
van a probar en el software. En la literatura existen diversos autores que proponen
taxonomas caracterizadas por su grado de profundidad o expansin.
La clasificacin propuesta por Burnstein se caracteriza por ser una
taxonoma generalizada, enfocada en tipos de pruebas tpicos en la industria del
software. La clasificacin incluye pruebas de: funcionalidad, de rendimiento, de
fatiga, de configuracin, de seguridad y de recuperacin.
Por otro lado existen taxonomas que buscan abarcar un conjunto de aspectos
ms amplio en las pruebas, lo cual conduce a que stas contengan una expansin
notable en la cantidad de tipos, ofreciendo una visin ms detallada del horizonte
de pruebas e influyendo positivamente en todo el proceso de pruebas. Myers
clasifica los tipos de pruebas en: de locacin, de volumen, de fatiga, de capacidad
de uso, de seguridad, de rendimiento, de almacenamiento, de configuracin, de
compatibilidad y conversin, de instalacin, de capacidad de ser confiable, de
recuperacin, de utilidad, de documentacin, de procedimientos y de aceptacin.

Las tcnicas de pruebas de software constituyen un mecanismo conceptual
mediante el cual se pueden detectar defectos en el software. En la taxonoma
citada por Young y Taylor, se puede observar que se tipifican las tcnicas de
pruebas de software teniendo en cuenta el ciclo de desarrollo del mismo y su
estado (caracterstica estticas o dinmicas).
Existen otras tcnicas no clasificadas segn su estado; es el caso de las citadas
por Burnstein as:
1. Pruebas de tipo aleatorio: se generan los valores correspondientes a los
casos de pruebas de forma aleatoria teniendo en cuenta la especificacin de las
entradas y en algunos casos las salidas. Algunos autores proponen tcnicas de
muestreo aleatorio con restricciones que permiten reducir la poblacin objetivo sin
afectar los hallazgos de defectos.
2. Pruebas de particin de clases equivalentes: La poblacin de entrada se
generan a partir del muestreo de conjuntos de valores llamados clases. Las clases
seleccionadas deben cubrir todo el dominio de valores de entrada o salida y no
deben traslaparse. Aunque existe una dificultad asociada en el diseo de pruebas
usando esta tcnica, la probabilidad de hallar defectos es bastante alta adems
elimina la necesidad de realizar pruebas exhaustivas.
3. Pruebas de valores lmite: Partiendo de la prueba de particin de clases
equivalentes se puede incorporar en los datos de pruebas, valores limites de las
clases particionadas, es decir, valores que se encuentran en el borde de una u
otra clase. Cuando se prueban los valores limites, la probabilidad de encontrar
defectos aumenta, dado que estos puntos son los ms susceptibles de contener
errores.
4. Pruebas de suposicin de error: La forma ms intuitiva de seleccionar valores
de prueba es a travs de la suposicin de errores la cual se basa en la experiencia
del diseador de pruebas. Esta tcnica pretende revelar defectos cuando se elijen
valores del dominio de entrada que producen determinados valores del dominio de
salida.

5. Pruebas de transicin de estados: Esta tcnica se basa en el diagrama de
transicin de estados construido para los objetos relevantes del sistema. El
diagrama de transicin de estados presenta los diferentes estados de un objeto y
los eventos que generan las transiciones. Cuando un diseador de casos de
prueba utiliza una tcnica de transicin de estados tabula las combinaciones
posibles que deben ocurrir para que un objeto pase de un estado a otro. Esta
informacin de secuencia de eventos es utilizada por el probador para buscar
falencias en los estados y sus transiciones.