Una mirada desde el desarrollo ágil a la Calidad Interna del software

En el taller “Evaluación de la calidad de productos de software” efectuado el 17 de mayo se pudo disfrutar de la conferencia magistral “Una mirada desde el desarrollo ágil a la Calidad Interna del software” impartida por el MSc. Anesto del Toro Almenares, jefe de producción de la División DATYS – 6 Villa Clara. El blog del SC7 comparte con todos sus lectores las ideas centrales.

Agenda de la conferencia:

  1. Problemas habituales
  2. Análisis de causa base
  3. Mediciones
  4. Prácticas recomendadas
  5. Conclusiones
Problemas habituales en los software/sistemas que se desarrollan
  • El sistema hace lo que dicen los requisitos, pero no lo que el cliente necesita.

El conferencista indagó que esto se debe a: trabajando en requisitos viejos; necesidades cambiantes, que incluye, incomprensión de un requisito, decisiones de los desarrolladores por considerarlo útil o interesante, solicitudes del cliente que posteriormente se percata que no lo describió correctamente, lo describió correctamente pero cuando lo vio implementado se percata que es algo incorrecto o lo describió correctamente pero ahora quieren algo diferente.

  • Funciona en la PC del desarrollador, pero no en producción.

El conferencista explicó que se debe a múltiples causas como pueden ser: falta de aislamiento para los entornos de prueba; dependencias en el sistema operativo del entorno de desarrollo ausentes en el de producción; falta de reproducibilidad del provisionamiento y despliegue (falta de automatización), no sandboxing, entre otras causas.

  • No se comporta correctamente bajo carga.
  • Introducción de bugs al liberar nuevas funcionalidades.

Ley del probador: El grado en que conoces cómo se comporta tu software será el grado en que lo hayas testeado con precisión.

Análisis de las causas de los problemas

El conferencista se centró en “Introducción de bugs al liberar nuevas funcionalidades”. Para ello reflexionó sobre los síntomas que se pueden apreciar cuando se está frente al problema ¿cómo construir el producto correcto, correctamente?:

  • Rigidez (cualquier “cambio” causa una cascada de cambios relacionados).
  • Fragilidad (cualquier “cambio” rompe cosas distantes y aparentemente no relacionadas).
  • Inmovilidad (el código es irremediablemente enredado; la reutilización es imposible).

El MSc. Anesto del Toro enfatizó que la solución está en el diseño incremental y una arquitectura evolutiva. Compartió con el auditorio la siguiente gráfica tomada de https://www.martinfowler.com/bliki/DesignStaminaHypothesis.html

Ley del cambio: Mientras más tiempo exista un software más probable es que cualquiera de sus partes requiera cambios.

Del Toro compartió con los participantes la ecuación para calcular la conveniencia del cambio (D), la cual relaciona el valor futuro del software (Vf) con el esfuerzo en mantenimiento (Em). D = Vf / Em

Ley de la ecuación de Diseño de Software: Es más importante reducir el esfuerzo de mantenimiento que el esfuerzo de implementación.

El conferencista auxiliándose de un pensamiento de Ward Cunningham realzó la importancia de la calidad del código fuente para alcanzar la productividad. “Podemos decir que el código es de elevada calidad cuando la productividad se mantiene alta en la presencia de cambios en el equipo y en los objetivos”.

Mediciones

El MSc. Anesto del Toro conceptualizó la relación entre la deuda técnica y el desarrollo ágil, sobresaliendo los siguientes puntos:

  • El desarrollo ágil considera el código fuente como un activo “principal”, no el modelo de diseño ni la documentación.
  • La definición de “código correcto” debe considerarse como parte de la DoD (definición de hecho), listado de requisitos de la calidad para el código fuente y nivel aceptable de deuda técnica.
  • El desarrollo ágil promueve la transparencia.
  • La deuda técnica debe ser identificada y monitoreada.
  • Los proyectos deben planear y priorizar actividades para “pagar” y limitar esta deuda.

Posteriormente preguntó al auditorio ¿Cómo medir? Buscando la solución reflexionó sobre cómo alcanzar la meta plantea:

  • Evaluación de la calidad del código fuente.
  • Intentan responder preguntas como: ¿Cuál es la calidad de software construido por los desarrolladores? ¿El código es modificable, mantenible, portable, reutilizable? ¿Cuál es la deuda de diseño de un Proyecto?
  • Estándares, como la ISO/IEC 25000, no proporcionan un soporte efectivo sobre la manera de construir una respuesta global.
  • Método sonarqube, se basa las mediciones a las características mantenibilidad, fiabilidad y seguridad. A través de las reglas ISSUES (code smell – manteniblidad; bug – fiabilidad; vulnerabilidades – seguridad). Y conceptualiza que la deuda técnica es el esfuerzo para solucionar el code smell.
  • Método SQALE. Los proyectos ágiles generan una gran cantidad de ciclos de cambio para el código. Las características de la calidad necesarias para respaldar estos desarrollos son la testabilidad, la fiabilidad y la capacidad de cambio. Si la deuda del código para estas tres características es demasiado alta, los desarrolladores se verán ralentizados en su productividad. Su código no es lo suficientemente “ágil”.
  • Evaluación de requisitos / reglas (análisis estático del código), para ello se utilizan herramientas automatizadas que varía en dependencia Entorno de Desarrollo Integrado (IDE).

Prácticas recomendadas

El MCs. Anesto del Toro hizo tres recomendaciones a todos los presentes en el taller:

  1. Desarrollo Ágil Guiado por Pruebas (Test Driven Development (TDD))

El conferencista se detuvo a explicar de qué trata el TDD, resumiéndolo en cuatro aspectos:

  • Método de desarrollo (diseño) no testing.
  • El objetivo es: “Código de calidad que funciona”.
  • Escribir los tests antes que el código, y refactorizar incrementalmente.
  • Pruebas para capturar errores de regresión.

Además, expuso los beneficios:

  • Inversión de productividad en el “futuro”.
  • Ahorro tiempo de debugging.
  • Creación de código con el que es más fácil trabajar.
  • Reducción del retrabajo.
  • Desarrolladores mejoran progresivamente.
  • Tests de regresión permiten refactorizar con confianza.
  • Refactor ayuda a mejorar el diseño del software y arquitectura.

Retos:

  • Costo inicial, presión de deadlines.
  • Rechazo inicial de adopción.
  • Tests lentos; muchos tests.
  • Subordinar diseño al TDD.

2. Revisiones de código

El conferencista se detuvo a explicar de qué trata la revisión de código, resumiéndolo en cinco aspectos:

  • El código escrito por un desarrollador es revisado por “otros”.
  • “Evaluación crítica” línea a línea en un contexto de “NO amenaza”.
  • Meta es cooperación, NO encontrar fallas.
  • Mecanismo integrado al proceso de codificación.
  • Disminución de los costos. Empleo de herramientas especializadas (ACS).

Además, expuso los beneficios:

  • Garantizar cumplimiento de estándares de codificación.
  • Tutoría de nuevos desarrolladores (aprendizaje de errores).
  • Descentralizar propiedad del código.
  • Localización de code smells/bugs tempranamente.
  • Alternativa a pair-programming localizaciones distantes.
  • Establecimiento de relaciones de confianza y colaboración.

Retos:

  • Know-how + Know-why*
  • Mejores técnicos (costo tiempo)
  • Rechazo inicial, lentitud de adopción
  • Sistematicidad

3. Integración continua

El conferencista se detuvo a explicar de qué trata la integración continua:

  • Práctica de “integración” del código frecuentemente en “master” con el objetivo de reducir el gap entre un commit y el build + verificación, que posibilita detectar errores tan pronto como son impactados en el repositorio.

Además, expuso los beneficios:

  • Detección y solución problemas de integración de forma continua, evitando el caos de última hora.
  • Ejecución inmediata de las pruebas: unitarias, integración,…
  • Monitorización continua de las métricas de calidad del proyecto.
  • Disponibilidad constante de una versión para pruebas, demos,…
  • Check-in frecuente fuerza a los desarrolladores a crear código modular, de menor complejidad.

Retos:

  • Mentalidad de automatización y testing
  • Costo
  • Cola de integración en equipos muy grandes
  • Integración de código parcial (evitar CD)
Conclusiones
  • Importancia de la Calidad Interna del software
  • Relevancia del diseño
  • Gestión de la deuda técnica
  • Adopción de prácticas
  • Libros recomendados

La ilusión de hacer las cosas más rápido puede conducir a un crecimiento exponencial en el costo de mantenimiento de software.

Nota: Si desean descargar la presentación u otros materiales elaborados por el MSc. Anesto del Toro pueden acceder https://www.linkedin.com/in/anesto-del-toro

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *