Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Lecura Fundamental - Semana 01
Lecura Fundamental - Semana 01
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.)
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.
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 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
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
POLITÉCNICO GRANCOLOMBIANO 12