METODOLOGÍA PARA EVALUAR

LA CALIDAD DE LOS SISTEMAS DE INFORMACIÓN

Liliana del S. Gómez Arenas

lgomez@parquesoft.com
ParqueSoft
Cali, Octubre de 2004

Resumen
En este documento se presenta una metodología cuantitativa para evaluar la calidad funcional de
sistemas comerciales de información; el estado actual de la metodología, es el producto de la
experiencia aplicada en más de 50 productos comerciales desarrollados en ParqueSoft1 con el
patrocinio del programa InfoDev del Banco Mundial y en el que participaron activamente 18
Ingenieros de Pruebas durante 18 meses.

1. Introducción

Una de las principales estrategias que compone el modelo estratégico de ParqueSoft, es la CCA-
Certificación de Calidad, que se ocupa de la definición e implementación de los procesos de
calidad necesarios para darle viabilidad al desarrollo de software como actividad de ingeniería
aplicada para hacer negocios.

La metodología BaQEM (Bussines Application Quality Evaluation Method) para hacer pruebas
funcionales a sistemas de información se comenzó a desarrollar a finales del 2002, con el
propósito de aportar una metodología cuantitativa, práctica y efectiva para evaluar y analizar la
calidad de los sistemas de información desarrollados en ParqueSoft, independiente de la
metodología y plataforma tecnológica utilizada para su desarrollo.

En la primera sección de este documento se ilustra como la metodología de pruebas parte del
conocimiento de la Industria en temas relacionados con la calidad como el modelo CMM
[CMM01] o el estándar ISO9000 [Iso9000] y se complementa con las implicaciones de ser el
soporte metodológico de ParqueSoft, que actúa como catalizador en la apropiación de prácticas
de ingeniería aplicables a los procesos de negocios, es decir que requiere metodologías con alto
contenido, ágiles, basadas en el sentido común y orientadas al resultado.

En la sección 2 del documento, se presentan las etapas de la metodología, que como tal está
basada en la construcción de un modelo jerárquico de requerimientos de prueba, partiendo de las
procesos funcionales que soporta el producto a evaluar. De modo que, a partir de esas
funcionalidades se derivan procesos, subprocesos, y, a partir de éstos, siguiendo un proceso de
descomposición jerárquico, se identifican y especifican requerimientos de prueba que en otras
palabras son los atributos de calidad del producto.
Igualmente, se dedica la sección 3 del documento para presentar el nivel de soporte que brinda la
herramienta de software GreenVolution al proceso de aseguramiento de calidad definido en la
metodología BaQEM, además de mostrar un panorama de la misma.

1
ParqueSoft http://www.parquesoft.com
Cluster de empresas de base tecnológica especializadas en la industria del conocimiento, a
través del desarrollo de productos, soluciones y servicios de software.
Finalmente, se cierra el documento con una conclusión sobre los avances que se tienen previstos
para el futuro inmediato en la estrategia CCA de Certificación de Calidad, concretamente en lo
que respecta a la metodología de pruebas de sistemas de información.

2. Antecedentes

Bien sea que su inspiración partiera de las necesidades de los clientes, de la presión competitiva o
del simple deseo de mejorar su calidad y eficiencia, ParqueSoft se interesó a finales del año 2002
por los temas de Ingeniería de Software y Aseguramiento de la Calidad del software y como
respuesta a ésta inquietud, se dá inicio un estudio comparativo de los modelos de calidad hasta el
momento conocidos y más utilizados por la Industria a nivel mundial. Este estudio concluye a
principios del 2003 cuando se complementa el modelo estratégico de ParqueSoft con la estrategia
de CCA ~ Certificación de Calidad.

El propósito de la estrategia CCA es institucionalizar en la comunidad, los métodos de ingeniería

de software y acompañar a las compañías de desarrollo de software a través la aplicación de la
metodología definida para evaluar la calidad sus sistemas.

2.1 Modelos estudiados y evaluados

El Modelo CMM, Madurez de la Capacidad

El Capability Maturity Model, CMM2, o Modelo de Madurez de la Capacidad del Software,
definido en 1986 por el Software Engineering Institute, SEI de la Carnegie Mellon University,
despertó alto interés en la industria de software debido a que las primeras instituciones que lo
adoptaron, como el Departamento de la Defensa de los Estados Unidos, reportaron acerca de los
múltiples beneficios proporcionados, tanto cualitativos como cuantitativos.

El marco de referencia de la madurez, fundamento del Modelo de Madurez de la Capacidad

consiste en modelo de cinco niveles que incluyen 368 actividades, desde el nivel 2 al 5, para los
métodos de ingeniería en una organización de desarrollo de software comprometida con la
calidad.

En el tema específico de calidad, el modelo cuenta con la KPA de nivel 2, SQA-Software Quality
Assurance, cuyo propósito es proporcionar a la dirección la visibilidad apropiada en el proceso
usado por un proyecto de software y de los productos bajo construcción. La KPA tiene 4 metas,
que son en su totalidad heredadas por la estrategia CCA de ParqueSoft:

- Las actividades de SQA son planeadas.

- Se verifica objetivamente la adherencia de las actividades y productos de software a los
estándares, procedimientos y requerimientos.
- Las actividades y resultados de SQA son informadas a los grupos de trabajo e individuos
que están relacionados.
- Los problemas de no cumplimiento que no pueden ser resueltos por los equipos de
trabajo, son tratados a nivel de comités técnicos especializados.

2
http://www.sei.cmu.edu
El compromiso de ésta KPA, implica que la organización disponga de una política organizacional
escrita para aplicar la garantía de calidad, aspecto que se cumple en ParqueSoft a través de la
estrategia CCA.

Adicionalmente, se hereda de éste modelo la convicción de mantener en medios persistentes

todos los hallazgos de tal forma que a partir de dicha información sea posible analizar causas y
proponer planes de acción para hacer gestión de las desviaciones.

En general, en el estudio se concluyó que las 8 prácticas de SQA propuestas por el modelo
agregan valor, por lo tanto fueron incorporadas como actividades en la metodología de pruebas
definida para ParqueSoft.

El Modelo TickIT
En 1991, el Consejo Nacional de Acreditación de los Organismos de Certificación (National
Accreditation Council of Certification Bodies, NACCB), introdujo en el Reino Unido el
programa TickIT como respuesta a las quejas emitidas por las empresas dedicadas a la
elaboración de software con respecto a la calidad y consistencia de las evaluaciones para la
certificación ante la norma ISO 9001; el objetivo del programa TickIT era ayudar a las
organizaciones de software a crear sistemas de calidad que agregaran valor a sus empresas y que
cumplieran con la norma ISO 9001.

En términos generales al proceso de desarrollo de software, se adoptaron los siguientes elementos

del modelo:

- Análisis y especificación de los requerimientos del sistema de información asegurando que

sean revisados y acordados con el cliente.
- Planeación, control y monitoreo del avance del desarrollo respecto al plan comunicando a las
partes afectadas y que avise oportunamente de problemas potenciales.

Específicamente en Calidad:

- Se hace planeación de las actividades de calidad en los proyectos, especificando las

inspecciones, revisiones y pruebas requeridas durante el desarrollo.
- Se hacen Inspecciones de los productos usando como referente los estándares y
requerimientos aplicables.
- Se hacen pruebas de los entregables del diseño para verificar que satisfagan la especificación.
- En integración se proponen pruebas e inspecciones del sistema, para demostrar que el sistema
integrado funciona correctamente y satisface su especificación.
- Identificar, segregar, investigar y corregir productos no conformes.

El modelo TPI
TPI (Test Process Improvement) está basado en las mejores prácticas de la industria relativas a la
mejora del proceso de pruebas. El modelo incluye guías prácticas para evaluar el nivel de
madurez de pruebas de una organización así como los pasos para mejorar el proceso.

El modelo se compone de 20 Áreas Claves, que constituyen la base para mejorar y estructurar el
proceso de pruebas, de las cuales, fueron heredadas por la estrategia y metodología de Pruebas:
1. Estrategia de pruebas
2. Modelo del Ciclo de Vida
3. Estimación y Planeamiento
4. Técnicas de Diseño de Pruebas
5. Técnicas de Pruebas Estáticas
6. Métricas
7. Herramientas de Prueba
8. Entorno de Pruebas
9. Compromiso y Motivación
10. Funciones de Pruebas y capacitación
11. Comunicación
12. Informes
13. Manejo de Defectos
14. Administración del Testware (elementos de prueba)
15. Administración del Proceso de pruebas
16. Pruebas de Caja Blanca

Además de los tres modelos anteriormente mencionados, para la elaboración de la metodología

de pruebas funcionales de software, se tuvieron en cuenta las necesidades planteadas por la
filosofía ParqueSoft, de tal forma que la metodologías debía no solo tener un alto contenido, sino
que además debía ser ágil, actuar como soporte al proceso de desarrollo de software, estar basadas
en el sentido común y sobre todo debía estar orientada al logro de los resultados propuestos.

3. Metodología BaQEM para pruebas funcionales de software

Esta es una metodología de pruebas funcionales cuantitativa, estructurada en tres etapas:

ANÁLISIS, DISEÑO y EJECUCIÓN, que están compuestas por una serie de actividades que las
personas responsables de las pruebas deben ejecutar en el proceso.

La metodología se basa en la elaboración y posterior ejecución de un modelo jerárquico de

requerimientos de prueba:

Etapa I. Análisis. Los responsables de la evaluación deben conocer el dominio y entender el

alcance del sistema de información a probar, así como el proceso utilizado para su desarrollo,
para lo cual es fundamental que se informen además del entorno legal del producto, del mercado
y de la competencia.

En esta etapa se inicia la elaboración del modelo jerárquico de requerimientos de prueba

partiendo de las procesos funcionales que soporta el producto a evaluar. De modo que, a partir de
esas funcionalidades se derivan procesos, subprocesos y actividades que quedan registradas en el
entregable MDP-Matriz de Descomposición funcional.

Etapa II. Diseño. Los responsables de la evaluación deben identificar, acordar y especificar los
atributos y características de calidad que se van a probar. Esta actividad se hace siguiendo con el
proceso de descomposición jerárquico, a través del cual se identifican y especifican
requerimientos de prueba que quedan registrados en el entregable MRP-Matriz de
Requerimientos de Prueba.

A cada requerimiento de prueba, que de por si debe ser cuantificable, se le asocia un resultado
esperado de su dominio real, que podrá ser verificado. Un requerimiento de prueba es el último
nivel en la jerarquía y representa un atributo de calidad, que permite concluir si la aplicación hace
o no lo que debe hacer.

Enfoque para el diseño de las Pruebas

Recordando el objetivo de la pruebas, se diseñan pruebas que tengan la mayor probabilidad de
encontrar el mayor número de no conformidades con la mínima cantidad de esfuerzo y tiempo,
para lo cual existen fundamentalmente dos enfoques, que al combinarlos permite lograr mayor
efectividad:

- Pruebas de Caja Negra o Enfoque Funcional, hace referencia a pruebas que se llevan a cabo
a través de la interfaz gráfica del software (GUI). O sea, pretenden demostrar que las
funciones del software son operativas, que la entrada se acepta de forma adecuada y que se
produce una salida correcta, así como que la integridad de la información externa se
mantiene.
- Pruebas de Caja Blanca, son aquellas pruebas que se basan en los caminos lógicos del
software, la estructura interna y la implementación del software en pruebas, proponiendo
casos que ejerciten conjuntos específicos de condiciones y/o ciclos.

Para cada enfoque, existen diversas técnicas que enriquecen las posibilidades de los probadores
“para hacer más con menos”.

Tipos de Pruebas

Las técnicas de pruebas son aplicables para optimizar la identificación de requerimientos de

pruebas a todos los niveles — pruebas de unidad, de integración, de sistema, e inclusive para
pruebas de aceptación de cliente.

Unit Integration System Acceptance

Las pruebas de unidad están orientadas principalmente a validar el cumplimiento de los
estándares de presentación y demás características visuales de la aplicación como la salida de los
reportes y el “look and feel”.

Las pruebas de Integración se usan cuando el sistema ha sido desarrollado por módulos o
componentes y es necesario determinar que éstos funcionan conjuntamente o “integrados”

La pruebas del sistema incluye típicamente muchos subtipos de prueba como: funcionalidad,
usabilidad, seguridad, internacionalización y localización, confiabilidad y disponibilidad,
capacidad, funcionamiento, recuperación y portabilidad.

Las pruebas de aceptación, son las que se hacen con los clientes y define su aceptación del
sistema.

Etapa III. Ejecución. Durante ésta etapa, los responsables de la evaluación preparan las
condiciones del ambiente y los datos que se usarán para ejecutar las pruebas hasta obtener un
‘ambiente de pruebas controlado’ sobre el cual se ejecutan los requerimientos de prueba.

Con base en la experiencia de los proyectos desarrollados, se propone que la etapa de ejecución
de cada proceso de pruebas sea dividida en al menos 5 iteraciones de pruebas con sus respectivas
regresiones, es decir, 5 ciclos de ejecución de los requerimientos de prueba o subconjuntos de
requerimientos agrupados por algún criterio válido como por ejemplo la funcionalidad,
naturaleza, grado de estabilidad.

Los resultados obtenidos en cada iteración de pruebas, en términos de horas hombre (HH)
invertidas y cantidad de no conformidades por tipo son registrados en el entregable IAP-
Producto.doc, donde adicionalmente se presentan hallazgos generales relevantes y
recomendaciones.

Es responsabilidad de los probadores ejecutar la mayor cantidad posible de iteraciones y

regresiones3 de prueba hasta poder demostrar cuantitativamente que la cantidad de hallazgos en
cada iteración presentan una tendencia sostenida a la baja que permita concluir que se está
logrando la estabilidad funcional del producto de software.

Tendencia sostenida a la
baja.

Iteraciones de pruebas y
regresiones.

3
Ciclo de ejecución de pruebas, que busca asegurar que cualquier no conformidad encontrada en la iteración
inmediatamente anterior ha sido corregida y que ninguna de las funcionalidades liberadas previamente ha fallado como
resultado de las correcciones ó que las características nuevamente agregadas no han creado conflicto con las versiones
anteriores del software.
El responsable de pruebas analiza los resultados obtenidos en la prueba versus los resultados
esperados, con base en lo cual se determina la presencia de ‘no conformidades’. En éste análisis
se tiene en cuenta que no todas las discrepancias en los resultados esperados son ‘no
conformidades’, puesto que es posible que existan fallas en otros aspectos que en lo posible deben
ser descartados respetando el siguiente orden: los datos de prueba, la ejecución de los pasos de la
prueba, el ambiente de pruebas o la definición del requerimiento de prueba.

Las no conformidades identificadas durante el proceso se registran en la herramienta de tracking

del proceso productivo, GreenWay4, y la corrección de las mismas se realiza con base en el
acuerdo de nivel de servicio pactado (SLA) con el equipo técnico como parte de la planeación.
Las pruebas de regresión se ejecutan con base en los mismos instrumentos de pruebas funcionales
para asegurarse de que el código nuevo o el modificado (para dar solución a las no
conformidades identificadas durante las pruebas) todavía es conforme con los requisitos
especificados y que el código sin modificar no ha sido afectado por la actividad del
mantenimiento.

Etapa IV. Retroalimentación. Después de ejecutar las iteraciones propuestas de pruebas en el

plan de pruebas y/o haber logrado el criterio de cierre pactado, se llega a obtener la calidad
deseada en el producto de software.

El proceso de prueba termina con la elaboración y presentación de conclusiones y

recomendaciones tanto para el producto como para el proceso productivo. Esta información,
queda registrada en el entregable ICP-Empresa.doc y debe ser fácilmente analizable por el equipo
desarrollador para garantizar que será empleada eficientemente en actividades de reproceso y/o
toma de decisiones.

3.1 Criterio para determinar la liberación de producto

Idealmente, durante el proceso de pruebas se espera poder exponer el sistema a todas las
situaciones posibles, así se encontraría hasta la última no conformidad y con base en esto se
podría cerrar el proceso, sin embargo eso es imposible desde todos los puntos de vista: humano,
económico e incluso matemático.

Dado que todo es finito en programación (por ejemplo el número de líneas de código o el número
de variables, el número de valores en un tipo) se puede pensar que el número de pruebas posibles
también es finito. Esto deja de ser cierto en cuanto entran en juego ciclos, en los que es fácil
introducir condiciones para un funcionamiento sin fin. Aún en el irrealista caso de que el número
de posibilidades fuera finito, el número de combinaciones posibles es tan grande que se hace
imposible su identificación y ejecución a todos los efectos prácticos.

Sobre esta premisa de imposibilidad para determinar el logro de la perfección, en este caso la
estabilidad de una versión de un producto de software, es necesario buscar formas humanamente
abordables y económicamente aceptables de encontrar los criterios para determinar el punto de
cierre de pruebas, que debe quedar pactado desde el principio del proceso, en el plan de pruebas.

4. GreenVolution
Para soportar la metodología de trabajo, se cuenta con la Suite GreenVolution, compuesta por
cinco herramientas que buscan apalancar cada uno de los puntos neurálgicos asociados al proceso
de desarrollo de software:

4
Componente de la Suite GreenVolution.
Green-Way, es un componente que permite la planeación y seguimiento del trabajo de
un grupo de desarrollo en términos de los requerimientos o no conformidades asociadas
al proceso.
Green-Test, es la herramienta que controla y administra los entregables de las actividades del
proceso de pruebas de los productos de software.

Green-Notes, es la herramienta que permite la implementación de una dinámica de

documentación de las funcionalidades que se van incorporando en los releases o versiones de
productos de software a medida que se va avanzando en la construcción
del Road Map del producto.

Green-FAQs es una herramienta a través de la cual un equipo de trabajo puede construir un

repositorio en base de datos de preguntas frecuentes sobre las funcionalidades y características de
un producto de software de forma estructurada y escalable. El sistema permite no solo almacenar
las preguntas, sino también las respuesta y alternativas posibles de solución .

Green –Metrics, es una herramienta que reúne la información derivada de las otras aplicaciones y
con base en ella definir y calcula un conjunto de métricas estadísticas, informes e indicadores de
gestión, permitiendo a los equipos de trabajo tener retroalimentación sobre el estado de avance
del proyecto y en general del desempeño de los recursos invertidos en el proyecto.

5. Conclusiones

Emplear de forma sistemática y disciplinada modelos, métodos y herramientas de Ingeniería de

software para el aseguramiento de la calidad favorece no solo la comprensión, análisis, sino que
potencializa la mejora de la calidad producida. La metodología BaQEM, proporciona un enfoque
práctico, sistémico y cuantitativo para la evaluación de la calidad funcional de los sistemas de
información.

A la fecha, la metodología ha sido aplicada a más de 50 casos reales, en proyectos de desarrollo a

escala industrial, cada uno de los cuales ha dejado aportes significativos para la madurez de la
misma.

Por otra parte, el empleo de herramientas que brinden soporte a la metodología permite a los
responsables de las pruebas agilizar los procesos y minimizar las situaciones de riesgo e
imprecisiones. Uno de los principales objetivos de la estrategia CCA que se viene desarrollando
en ParqueSoft, consiste masificar el uso de la suite GreenVolution para obtener a través de esto
una base de información unificada a la que se le puedan aplicar técnicas de minería de datos para
obtener información sobre el perfil de la Industria en el sur-occidente Colombiano.

Referencias
1. MANAGING THE SOFTWARE PROCESS, Watts S. Humprey, Addison Wesley
2. SOFTWARE VERIFICATION AND VALIDATION, a Practitioner’ s Guide, Steven R.
Rakitin, Artech House
3. THE CAPABILITY MATURITY MODEL, Guidelines for improving the software process,
CMU, SEI, Addison Wesley
4. TPI – Test Process Improvement
5. ISO9000 version 2000 INALCEC