RECOMENDACIONES
Recomendaciones para la gestión de la calidad del software
- Incorporación temprana de la calidad
- Definición clara de requisitos
- Desarrollo incremental con retroalimentación
- Estandarización del código y revisiones técnicas
- Estrategia de pruebas por niveles
- Documentación suficiente y orientada al uso
- Medición de la calidad
- Gestión formal de incidentes y defectos
- Consideración de la seguridad como atributo de calidad
- Adaptación al contexto educativo y al contexto productivo
- Ciclo de mejora continua
Incorporación temprana de la calidad
La calidad del software debe considerarse desde las etapas iniciales del proyecto y no únicamente al finalizar el desarrollo. Para ello, es necesario establecer desde el comienzo qué se entiende por “calidad” en el contexto del sistema: disponibilidad, cumplimiento funcional, rendimiento, facilidad de uso u otros atributos. Estos criterios deben documentarse como condiciones de aceptación o listas de verificación asociadas a cada funcionalidad.
La calidad del software debe considerarse desde las etapas iniciales del proyecto y no únicamente al finalizar el desarrollo. Para ello, es necesario establecer desde el comienzo qué se entiende por “calidad” en el contexto del sistema: disponibilidad, cumplimiento funcional, rendimiento, facilidad de uso u otros atributos. Estos criterios deben documentarse como condiciones de aceptación o listas de verificación asociadas a cada funcionalidad.
Definición clara de requisitos
Es indispensable contar con requisitos completos, no ambiguos y verificables. Debe diferenciarse entre:
Es indispensable contar con requisitos completos, no ambiguos y verificables. Debe diferenciarse entre:
-
Requisitos funcionales: describen los servicios y funciones que el sistema debe proporcionar.
-
Requisitos no funcionales: establecen restricciones o atributos de calidad, tales como desempeño, seguridad, usabilidad o portabilidad.
La experiencia demuestra que los requisitos no documentados tienden a no implementarse o a implementarse de forma inconsistente.
Desarrollo incremental con retroalimentación
Se recomienda trabajar mediante iteraciones cortas que generen entregables parciales evaluables por los interesados. Cada iteración debe permitir la demostración del producto para recibir retroalimentación temprana, lo cual reduce el costo de corrección y favorece la alineación con las expectativas del usuario.
Se recomienda trabajar mediante iteraciones cortas que generen entregables parciales evaluables por los interesados. Cada iteración debe permitir la demostración del producto para recibir retroalimentación temprana, lo cual reduce el costo de corrección y favorece la alineación con las expectativas del usuario.
Estandarización del código y revisiones técnicas
Para preservar la calidad técnica, el equipo de desarrollo debe adoptar convenciones comunes de codificación, nomenclatura y organización de archivos. Asimismo, es conveniente realizar revisiones de código (code review) entre pares con el fin de detectar errores lógicos, malas prácticas o vulnerabilidades de forma previa a la integración. Cuando sea posible, se sugiere complementar este proceso con herramientas de análisis estático.
Para preservar la calidad técnica, el equipo de desarrollo debe adoptar convenciones comunes de codificación, nomenclatura y organización de archivos. Asimismo, es conveniente realizar revisiones de código (code review) entre pares con el fin de detectar errores lógicos, malas prácticas o vulnerabilidades de forma previa a la integración. Cuando sea posible, se sugiere complementar este proceso con herramientas de análisis estático.
Estrategia de pruebas por niveles
El aseguramiento de la calidad no debe concentrarse en una única fase de prueba, sino distribuirse en varios niveles:
El aseguramiento de la calidad no debe concentrarse en una única fase de prueba, sino distribuirse en varios niveles:
-
Pruebas unitarias, orientadas a validar el comportamiento de funciones o componentes individuales.
-
Pruebas de integración, para verificar la correcta interacción entre módulos.
-
Pruebas funcionales o de sistema, destinadas a confirmar el cumplimiento de los requisitos especificados.
-
Pruebas de regresión, para asegurar que las modificaciones no introduzcan fallos en funcionalidades previamente operativas.
-
Pruebas de aceptación con el usuario, especialmente pertinentes en entornos formativos o cuando existe un “cliente” que debe validar el producto.
En proyectos de menor envergadura, al menos deben documentarse los casos de prueba ejecutados y sus resultados.
Documentación suficiente y orientada al uso
La documentación debe ser adecuada al propósito del sistema y a su ciclo de vida. Como mínimo, se recomienda disponer de: descripción general, instrucciones de instalación o despliegue, perfiles de usuario, lista de casos de prueba ejecutados y evidencia de su resultado. En entornos organizacionales, esta información facilita las labores de soporte; en entornos educativos, constituye evidencia del proceso.
La documentación debe ser adecuada al propósito del sistema y a su ciclo de vida. Como mínimo, se recomienda disponer de: descripción general, instrucciones de instalación o despliegue, perfiles de usuario, lista de casos de prueba ejecutados y evidencia de su resultado. En entornos organizacionales, esta información facilita las labores de soporte; en entornos educativos, constituye evidencia del proceso.
Medición de la calidad
La gestión de la calidad requiere indicadores. Aun cuando el proyecto sea pequeño, es aconsejable medir algunos aspectos básicos, tales como:
La gestión de la calidad requiere indicadores. Aun cuando el proyecto sea pequeño, es aconsejable medir algunos aspectos básicos, tales como:
-
Porcentaje de casos de prueba exitosos.
-
Número de defectos detectados por iteración o versión.
-
Tiempo de respuesta promedio en funcionalidades críticas.
Cuando un indicador presenta una tendencia negativa, deben definirse acciones correctivas (refactorización, ampliación de pruebas, optimización de consultas, entre otras).
Gestión formal de incidentes y defectos
Todo defecto identificado debe registrarse con la información necesaria para su reproducción: descripción, entorno, pasos seguidos y severidad. La atención debe priorizar los incidentes que impiden la operación, seguidos por aquellos que afectan significativamente la experiencia del usuario y, finalmente, los de carácter estético. Ningún incidente debe cerrarse sin verificación posterior.
Todo defecto identificado debe registrarse con la información necesaria para su reproducción: descripción, entorno, pasos seguidos y severidad. La atención debe priorizar los incidentes que impiden la operación, seguidos por aquellos que afectan significativamente la experiencia del usuario y, finalmente, los de carácter estético. Ningún incidente debe cerrarse sin verificación posterior.
Consideración de la seguridad como atributo de calidad
La seguridad de la información forma parte de la calidad del software. Por ello, es necesario:
La seguridad de la información forma parte de la calidad del software. Por ello, es necesario:
-
Validar sistemáticamente las entradas del usuario.
-
Evitar la exposición de mensajes de error técnicos al usuario final.
-
Proteger credenciales, claves y parámetros de configuración, evitando su publicación o inclusión en repositorios.
La incorporación de estas prácticas reduce la probabilidad de fallos en producción y de exposición de datos.
Adaptación al contexto educativo y al contexto productivo
-
En contextos educativos, el énfasis debe ponerse en la demostración del proceso completo (especificación, diseño, construcción, prueba y evidencia), aun cuando el producto sea de pequeña escala.
-
En contextos reales o productivos, el énfasis debe orientarse hacia la mantenibilidad, la claridad del código, la disponibilidad de guías de instalación y la trazabilidad de los cambios, de forma que el sistema pueda ser operado y soportado por terceros.
Ciclo de mejora continua
Tras cada entrega o liberación, es conveniente realizar una breve evaluación del proceso para identificar demoras, errores recurrentes o actividades susceptibles de automatización. A partir de dicho análisis pueden ajustarse plantillas de requisitos, listas de verificación de despliegue, suites de prueba o políticas de revisión de código, con el fin de fortalecer progresivamente la calidad del software producido.
Tras cada entrega o liberación, es conveniente realizar una breve evaluación del proceso para identificar demoras, errores recurrentes o actividades susceptibles de automatización. A partir de dicho análisis pueden ajustarse plantillas de requisitos, listas de verificación de despliegue, suites de prueba o políticas de revisión de código, con el fin de fortalecer progresivamente la calidad del software producido.