Unidad 1 / Escenario 1

Lectura fundamental

Calidad de software

Contenido
1 La calidad en pocas palabras

2 Procesos de mejora

3 Pruebas de software

4 Notas finales

Palabras clave: tipologías turísticas, turismo tradicional, turismo alternativo, turismo sol y playa, turismo negocios,
turismo cultural, ecoturismo, turismo aventura.
1. La calidad en pocas palabras

La calidad en software se puede asociar a temas etéreos, como el color y distribución de los
campos en una pantalla, a si es de fácil o difícil comprensión por parte de un usuario que no es
especializado en el proceso a realizar o, en el peor de los casos, la calidad puede ir de la mano
de respuestas parecidas a “es que yo me imaginaba algo diferente”. No estamos hablando de
situaciones irreales sino de expresiones que he escuchado en mi vida profesional.

El punto importante que puede sacarnos de ese embrollo es definir la calidad como el
cumplimiento de unos criterios de éxito, para determinar si el producto sirve a la necesidad
del cliente. Esto debe hacerse en las etapas tempranas del proyecto, pues, de otro modo,
la indefinición precisa de los requisitos del cliente y la correspondiente definición de
requerimientos y la forma de medir su cumplimiento tendrán consecuencias al momento de
la entrega.

Esto se puede observar en el reporte del caos que el Standish Group entrega año a año
(Hastie y Wojewoda, 2015). El porcentaje de proyectos dudosos es mayor al 50%; es decir,
hay opiniones encontradas sobre: si el proyecto fue exitoso o un fracaso. Por supuesto,
la diversidad de los interesados en el proyecto genera distintas opiniones, a la luz de su
perspectiva personal y rol en el equipo, pero esto es precisamente lo que debe acotarse. La
anuencia y aprobación de factores de éxito darán prioridades e importancia para considerar
que el producto cumple o no con calidad a lo solicitado.

La calidad no se puede medir al final del proyecto; debe monitorearse a lo largo de su ejecución
porque si las labores de corrección se llevan a cabo una vez se ha sido producido el daño, se
aumentan los costos de reparación y se deben reacomodar planes y cronogramas. Por lo tanto,
se debe evitar apagar incendios y debe anticiparse a los errores, en aras de prevenirlos, al revisar
los factores de riesgo continuamente, como se observa en la Figura 1. Un plan de gestión de
la calidad debe integrarse al proyecto en su fase de inicio, tal como lo determina la Guía de los
fundamentos para la dirección de proyectos del PMI (Guía del PMBOK).

POLITÉCNICO GRANCOLOMBIANO 2
Figura 1. Riesgos
Fuente: Basketman23 (s.f.)

Por supuesto, la calidad no es gratis. El proceso de llevar a cabo el aseguramiento de la calidad

implica destinar tiempo, dinero y recursos de todos los involucrados para documentar, medir,
analizar y plantear acciones preventivas. Pero, de nuevo, las consecuencias de no llevar un proceso
de este tipo generan estadísticas desastrosas a nivel global. De acuerdo con el reporte del caos, en
2015, un terrible 29% de proyectos de software fueron exitosos (Hastie y Wojewoda, 2015).

Aunque es claro, solo cuando el producto o parte del mismo está en un estado terminal de
elaboración se puede probar y entregar. También es válido que el seguimiento de estándares
de calidad en cada proceso o etapa de construcción y el despliegue de herramientas en cada
una de ellas nos debiera llevar a mejores resultados.

Por supuesto se requiere involucrar la cultura empresarial y organizacional, se deben mezclar

aspectos de varias empresas (el cliente, proveedores y el desarrollador, por lo menos) y formas
de pensar que aportan y afectan de acuerdo al compromiso y ética de cada individuo en el
grupo de trabajo. Por otra parte, los costos de calidad y el esfuerzo requerido para cumplirla,
que se generan con los procedimientos, estándares, métricas y precauciones normalizadas, a
veces llevan a querer simplificar o dejar de lado esas actividades, en aras de reducir el tiempo y
costos. Esto obvia que no se pueden obtener productos que aún no se han construido con las
tres B: buenos, bonitos y baratos; y mucho menos a tiempo.

POLITÉCNICO GRANCOLOMBIANO 3
 En síntesis...
En sus inicios, la gestión de calidad se basó en la detección de errores
y lograr la uniformidad de los productos, a través de la inspección total
de los mismos y su corrección. Solo después se usó la estadística para
determinar las variaciones en la calidad y usarla para detectar la causa
y migrar hacia la prevención.

Por lo tanto, un proyecto debe tener una justificación (muchos le dicen anteproyecto) que
establezca con claridad para todos los involucrados el beneficio tangible, o no, que traerá
la inversión. La justificación debe convencer a los interesados que el proyecto requiere lo
mejor de cada uno y que este tendrá cambios en el camino que afectan los costos, tiempo y
recursos. Es rango de incertidumbre debe asumirse, debe ser controlado con verificaciones
en todas y cada una de las actividades desarrolladas, ese objetivo necesario debe lograrse con
la ayuda de todos.

Las tendencias en software avanzan hacia los métodos de desarrollo ágil (no confundir con
rápido, entender que es por entregas cortas, revisión y ajuste dinámico del plan del proyecto a
medida que avanza, como se observa en la Figura 2) basados en conseguir el mejor producto
posible con la sinergia de las partes involucradas en el proyecto y un compromiso de buenas
acciones expuestas en el manifiesto para el desarrollo ágil de software (Manifesto for Agile
Software Development, s. f.).

Este modo de llevar los negocios, de manera justa y retroalimentada para todas las partes, va
en crecimiento por los resultados obtenidos. Se aparta de la antigua tradición de llevar a cabo
un proyecto por el contrato realizado.

POLITÉCNICO GRANCOLOMBIANO 4
Figura 2. Ciclo de desarrollo
Fuente: Basado en Brown (s.f.)

El PMBOK indica que, al momento de dividir el proyecto en tareas, las mismas no deben
superar el 4% del proyecto o una semana en tiempo. Esto en aras de dividir el proyecto tanto
como sea posible en entregables que puedan cerrarse al término de cada semana. Si alguna
tarea supera los límites debe dividirse.

2. Procesos de mejora

Cualquiera que sea la opción de desarrollo o ciclo de vida escogido, ello no exime de posibles
cambios recurrentes y de la evolución del producto a medida que pasa el tiempo. Por ello,
se requiere ser rápido en la evaluación de los cambios justificados y controlar lo que se está
probando, a efectos de que los errores se detecten lo más pronto posible y se permita la
integración con los demás participantes para tener en cuenta los cambios aprobados.

Para asegurar la calidad, las inspecciones y auditorías en un ambiente dinámico deben hacerse
sobre estados controlados del producto desarrollado, pues con un equipo de trabajo atacando
diversos frentes y con actividades en paralelo mantener la coherencia puede ser un problema.

POLITÉCNICO GRANCOLOMBIANO 5
Por ello, es necesaria la administración de configuraciones: un ambiente de pruebas con control
de versiones, como lo dicta el CMM (Modelo de Madurez de la Capacidad) para su nivel 2 (SEI
2001), en el cual indica que la empresa debe tener procesos formalizados para la administración
de requerimientos, planeación monitoreo y control del proyecto, aseguramiento de la calidad
de procesos y del producto, mediciones y análisis de las mismas, el control de versiones, la
identificación de componentes y el control de los cambios realizados.

Un plan de aseguramiento de la calidad debe definir la forma como se reportan los errores,
la forma como se evalúan y se aprueban las acciones correctivas y el modo en que se
implementan los cambios necesarios. Lo que se busca es el mejoramiento continuo de
los procesos que se aplican al desarrollo de software, en aras de obtener la excelencia,
medida desde la calidad del producto de software entregado. Está claro que el desgaste en
correcciones aumenta en la medida que la detección del error se retarda. Por lo tanto, la
calidad se debe asegurar a lo largo del proceso de construcción y fomentarse como filosofía
empresarial a largo plazo para la reducción de costos y esfuerzo.

En proyectos de desarrollo de software cada proyecto es diferente, depende del producto

a desarrollar, de la gente con la cual se debe interactuar, del ambiente organizacional del
cliente, de la plataforma en la cual se entregará, del lenguaje usado, etc. No se asimila a una
empresa en el sentido estricto de tener un molde, troquel o línea de fabricación que se pueda
usar para producir el mismo producto en masa una y otra vez. La gran diferencia es que el
producto cambia en cada caso, de allí la importancia de los procesos para asegurar la calidad
del software.

En síntesis...
Luego de superar los problemas de la cadena de producción, se llevó
la gestión de calidad a toda la empresa reconociendo que los costos
de producción están repartidos en todas las áreas de soporte y que lo
importante es el cliente.

POLITÉCNICO GRANCOLOMBIANO 6
Un proceso define un modo de hacer las cosas, reúne las buenas prácticas y usa las
herramientas que a lo largo del tiempo se han considerado adecuadas para mejorar las
actividades llevadas a cabo. En este orden de ideas, los procesos son más importantes porque
el entendimiento y seguimiento de sus criterios, normas, documentación, reportes, formatos,
revisiones y análisis nos permiten aplicar las técnicas a todo desarrollo independientemente de
sus condiciones específicas.

En síntesis...
Las tendencias actuales en gestión de calidad apuntan a la mejora
continua, basada en los procesos y la planeación a largo plazo como
motor de liderazgo en un mundo cada vez más competitivo en el que
hay que satisfacer al cliente con innovación.

El PMI, el CMM, las normas ISO y cualquier otro modelo de calidad se basa en criterios que
recogen lo dicho, lo que potencia un objetivo a largo plazo, medido, analizado y mejorado que
se basa en el beneficio de todos los involucrados: personal, cliente, proveedor, el producto y
lo más importante: dinámico y colaborativo para fundir el interés común y dejar de lado los
particulares en aras de obtener lo mejor para todas las partes.

Esto requiere mejora, no solo en las áreas de producción sino a lo largo y ancho de toda la
empresa, con motivación, educación, incentivos y premios a la mejora continua, que si bien
cuestan, a largo plazo dan estructura y apalancamiento para un mejor futuro.

POLITÉCNICO GRANCOLOMBIANO 7
3. Pruebas de software

Dado que la calidad se basa en el producto entregado, las pruebas de software a lo largo
de todo el proceso de desarrollo son fundamentales para establecer que la construcción
del producto se está realizando con el cumplimiento de los requisitos y objetivos fijados
por el cliente. Un enfoque muy intuitivo de hacer pruebas es basarse solo en los datos de
entrada y determinar que la salida sea correcta. A esto llamaremos pruebas de caja negra
o funcionales porque no nos interesa saber qué se hace en el programa o las condiciones
internas del desarrollo, solo basta saber del cliente qué resultados se esperan en cada caso
y con ello determinar si se cumplen o no. Esto se puede hacer desde la misma definición de
requerimientos, de tal suerte que se tenga una lista de casos de prueba a verificar en papel (a
mano), en prototipos o en un estado de avance de una función en particular.

De no tener suficientes casos diferentes que prueben todas las combinaciones posibles, se
pueden pasar errores. Para cubrir esto, se usa la técnica de pruebas de caja blanca o prueba
estructural. En ella se conoce el flujo de acciones que sigue el programa o función particular
en prueba y se generan datos para probar cada camino o ruta de ejecución del programa.
Es más costosa que la anterior, pues los casos de prueba se crean de acuerdo a como se
programó el código fuente y se afectan por el cambio de especificación o correcciones de
desarrollo.

Las pruebas se llaman estáticas si se realizan sin necesidad de ejecutar el código y se conocen
como pruebas de escritorio. Estas se basan en la validación del flujo de la información y
la transformación sobre ella realizada. Si, por el contrario, se corren sobre el programa,
las llamaremos dinámicas. Del mismo modo diremos que son manuales si no usamos una
herramienta de automatización que las ejecute de modo automático, a través de programas
que realizan las pruebas cada vez que de cambia parte del código. Por supuesto, esto ayuda
mucho siempre y cuando los casos de prueba sean representativos.

Las pruebas de acuerdo a la cobertura que tengan se llamarán unitarias si prueban solo un
elemento, pruebas de integración si prueban los elementos nuevos que se van adicionando
a un programa, pruebas de sistema una vez que se tiene un conjunto amplio de funciones,
pruebas de aceptación a la entrega al usuario y en algunos casos pruebas beta a las versiones
en liberación controlada y no aceptadas formalmente.

POLITÉCNICO GRANCOLOMBIANO 8
Hay pruebas diferentes, de acuerdo al objetivo de la misma, y que se definen por su
nombre. Por ejemplo, pruebas de seguridad, de carga, de rendimiento, de concurrencia,
etc. Todas las pruebas deben cumplir el plan, seguir sus normas, respetar sus cronogramas,
la documentación, realizarse por el responsable; determinar las fallas, los planes y cambios
necesarios para su corrección dentro del avance y etapas del proyecto total para entregar
el producto de software. Las alertas tempranas y el análisis de riesgos sirven para evadir las
fallas y ahorrar en tiempo y recursos, dando prioridad a los casos de prueba críticos por lo
que se requiere su clasificación y criterios de cumplimiento. Las pruebas se llevan a cabo por
diferentes personas: por el desarrollador, los pares, por el grupo de prueba interno, el grupo
de inspección, por auditores, por el usuario, etc. El propósito es aunar esfuerzos de un modo
controlado y bajo un marco definido en el plan de aseguramiento de la calidad.

4. Notas finales

La calidad es un concepto que debe ser concertado entre quienes desarrollan y aquellos
que reciben y utilizarán el producto creado. Los criterios así definidos darán una escala, una
clasificación, en orden de importancia para lograr el mejor producto con un costo beneficio
razonable y centrado en lo importante para el cliente. La calidad, aunque basada en el
producto, es una filosofía de vida y empresarial a largo plazo que se debe desplegar a nuestro
trabajo en todas su etapas y tareas realizadas para la mejora continua. Todo esto con el
objetivo de obtener crecimiento personal, laboral y social, lo que ahorra esfuerzos, tiempo y
costos innecesarios en rehacer tareas.

Las pruebas, inspecciones y auditoría son parte del plan, proceso, administración, gestión y
aseguramiento de la calidad. Se deben llevar a cabo a lo largo de todo el proyecto y en cada
una de sus etapas, con el fin de anticipar y eliminar los errores desde sus fases tempranas.
Mientras más se avance en el proceso de construcción del producto de software a entregar
en el proyecto, más altos son los costos de reparación y cambio en tareas ya ejecutadas que
deben rehacerse y el control de cambios y manejo de versiones son carga administrativa y de
comunicación. Esto afectan aún más el tiempo en correcciones.

POLITÉCNICO GRANCOLOMBIANO 9
Referencias
Basketman23. (s.f.). Busines woman and risk management concept [Fotografía]. Recuperado
24 de abril de 2018, a partir de https://www.123rf.com/search.

Brown, M. (s.f.). Project Management business product development arrows cycle [Ilustración].
Recuperado 24 de abril de 2018, a partir de https://www.123rf.com/search.

Carnegie Mellon University. (2001). Capability Maturity Model® Integration (CMMISM), Version
1.1 for Systems Engineering and Software Engineering. Recuperado 24 de abril de 2018, a partir de
https://resources.sei.cmu.edu/asset_files/technicalreport/2001_005_001_14009.pdf.

González, G. C., Domingo, N. R., & Pérez, M. Á. S. (2013). Técnicas de mejora de la calidad.
Madrid. UNED - Universidad Nacional de Educación a Distancia. Recuperado 24 de
abril de 2018, a partir de https://ebookcentral-proquest-com.loginbiblio.poligran.edu.co/
lib/bibliopoligransp/detail.action?docID=3216137&query=T%C3%A9cnicas%20de%20
mejora%20de%20la%20calidad

Gutiérrez, H. (2013). Control estadístico de la calidad y Seis Sigma (3a. ed.). México, D.F.,
MX: McGraw-Hill Interamericana. Recuperado 24 de abril de 2018, a partir de https://www.
ebooks7-24.com/book.aspx?i=280

Gutiérrez, H. (2014). Calidad y productividad. (4a. ed.). México, D.F., MX: McGraw-Hill
Interamericana. Recuperado 24 de abril de 2018, a partir de https://www.ebooks7-24.com/
book.aspx?i=751

Hastie, S., Wojewoda, S. Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch.
(s. f.). Recuperado 24 de abril de 2018, a partir de https://www.infoq.com/articles/standish-
chaos-2015

Hernándes, P. F. Á., & Ricardo, Z. P. M. (2006). Glosario de Términos Informáticos.

Córdoba, AR: El Cid Editor. Recuperado 24 de abril de 2018, a partir de https://
ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/bibliopoligransp/
detail. action?docID=3167493&query=Glosario%20de%20T%C3%A9rminos%20
Inform%C3%A1ticos
Manifesto for Agile Software Development. (s. f.). Recuperado 24 de abril de 2018, a partir
de http://agilemanifesto.org/

Marcelino, A. M., & Ramírez, H. D. (2014). Administración de la calidad: nuevas perspectivas.

México, D.F., MX: Grupo Editorial Patria. Recuperado 24 de abril de 2018, a partir de
https://ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/bibliopoligransp/detail.
action?docID=3227569&query=Administraci%C3%B3n%20de%20la%20calidad:%20
nuevas%20perspectivas

Pressman, R. (2010) Ingeniería del software un enfoque práctico (7a. ed.). México, D.F., MX:
McGraw-Hill Interamericana. Recuperado 24 de abril de 2018, a partir de https://www.
ebooks7-24.com/book.aspx?i=686
 INFORMACIÓN TÉCNICA

Módulo: Pruebas y calidad de software

Unidad 1: Calidad de software y el ciclo de vida de
las pruebas.
Escenario 1: Calidad de software

Autor: Nelson Pérez

Asesor Pedagógico: Manuel Fernando Guevara

Diseñador Gráfico: Alejandro Torres
Asistente: Daniela Mejia Ulloa
Este material pertenece al Politécnico Grancolombiano.
Por ende, es de uso exclusivo de las Instituciones
adscritas a la Red Ilumno. Prohibida su reproducción
total o parcial.

POLITÉCNICO GRANCOLOMBIANO 12