Existen diferentes tipos de pruebas que pueden utilizarse para comprobar que el código software de una aplicación funciona correctamente. Sin embargo, estas pruebas no son apropiadas cuando lo que se busca es verificar el rendimiento de la aplicación o la seguridad de su código. En esos casos, no habrá más remedio que recurrir a herramientas específicas o a una consultoría especializada para los diferentes tipos de análisis.
Análisis estático de código
El análisis estático de código ayuda, en esas situaciones, a poner de manifiesto:
- Los problemas no funcionales del aplicativo.
- La evidencia de problemas potenciales en etapas tempranas del ciclo de vida del software.
- La prevención de problemas potenciales en etapas tempranas del ciclo de vida del software.
- Todo ello sin pretender ocupar el lugar de una herramienta de pruebas de carga o el de una específica de seguridad.
Una ventaja importante del análisis estático de código es que proporciona importantes ahorros de costes. Al poder anticipar este análisis estático posibles problemas antes de que se hagan realidad, la organización puede evitar el gasto que suponen las correcciones de defectos. No lo olvidemos; los gastos aumentan exponencialmente a medida que va avanzando el ciclo de vida. Es decir, cuanto más tarde se descubra un defecto en el código fuente o código objeto, más caro resultará resolverlo.
Las buenas prácticas establecidas por el modelo TMMi para mejorar la calidad así lo corroboran. Incluso en los niveles de madurez 2 y 3 ya establece la necesidad de detectar defectos en las fases iniciales del ciclo de vida y es que el coste de corregir un defecto en producción puede ser hasta 70 veces superior que si se hubiera detectado al inicio del proyecto.
¿Cómo abordar el análisis estático de código?
Para abordar de forma más clara los distintos análisis de código es necesario clasificar las características del código software en Factores de Salud, que serán diferentes según los estándares que se apliquen.
Características del código
De forma genérica podemos agrupar las características del código en:
- Confiabilidad: Se trata de evitar comportamientos inesperados. Es necesario controlar todos los casos posibles y no realizar operaciones que provoquen resultados indeterminados.
- Rendimiento: Los recursos no son ilimitados. Hay ocasiones en las que tendemos a pensar que todo se soluciona asignando más recursos, pero es conveniente un uso eficiente de los los recursos existentes.
- Seguridad: La información debe estar suficientemente compartimentada, cada usuario debe poder acceder solo a aquello para lo que tiene permiso.
- Mantenibilidad: Cualquier cambio que haya que abordar será tanto más traumático cuanto más complejo y peor documentado sea el código.
Los factores como la confiabilidad, rendimiento y seguridad buscan evitar riesgos en el entorno productivo, mientras que la mantenibilidad y factores similares pretenden dar una idea del coste de propiedad del software.
Hay que tener también en cuenta que cada lenguaje de programación presenta sus particularidades y buenas prácticas. Éstas se traducen en reglas que se asignan a los factores de salud mencionados. Así, no es lo mismo analizar código Cobol que Java, y aunque pueden compartir algunas reglas, otras serán específicas del lenguaje.
Por otra parte, habría que decidir, a la hora de ejecutar un análisis, la conveniencia de acudir al análisis manual o al automatizado. Los criterios para elegir uno u otro vienen condicionados por aspectos como:
- La tecnología que se pretende analizar,
- El método de licenciamiento preferido por la organización o
- El establecimiento de prioridades, es decir la necesidad de una mayor profundidad en el análisis frente a un mayor tiempo de respuesta.
Cuando se prestan servicios de análisis manual de código estático no es necesario disponer de ninguna herramienta, aunque sí de un profundo conocimiento:
- Del lenguaje y sus buenas prácticas,
- Del entorno y el contexto del cliente.
- Si se trata de análisis automatizado, habría que acudir a herramientas como Cast, Kiuwan, SonarQube o PMD.
Finalmente, es necesario tener en cuenta que, aunque el análisis de código estático sea automatizado, el resultado está sujeto a interpretación. Algunas reglas en algunas herramientas de análisis causan falsos positivos o pueden no ser de aplicación en ciertos ámbitos.
Casos prácticos del método estático
En el momento en que el método estático se introduce en el ciclo de vida se produce un cambio en los equipos de desarrollo. Se dan ocasiones en las que se adoptan malas prácticas simplemente por el hecho de que “siempre se ha hecho así”. En estos casos, el efecto de evidenciar el problema, explicar y justificar la forma correcta de hacerlo, suele ser inmediato.
Algunos estudios de MTP sobre el rendimiento y seguridad de las aplicaciones
MTP ha llevado a término algunos estudios ha llevado a término algunos estudios sobre la correlación entre incidencias en producción y calidad de código.
Por ejemplo, para una compañía del sector de utilities se determinó que solo 16 objetos que aglutinaban el 80% de las incidencias de producción del último año resultaron ser, con mucha diferencia, los más complejos y peor documentados de entre los 22.000 evaluados.
En otro caso fue posible encontrar la causa de las continuas caídas en producción de un aplicativo en la deficiente liberación de recursos que se llevaba a cabo. Este problema suele ser recurrente y conviene detectarlo cuanto antes.
Recientemente, se ha detectado en un aplicativo en desarrollo en el que no se reutilizaban las conexiones a base de datos, resultando en un rendimiento paupérrimo. Como consecuencia, se recomendó la aplicación de un pool de conexiones, con la consiguiente mejora en rendimiento.
¿Qué es la deuda técnica?
El término deuda técnica no solo es aplicable al análisis estático de código. Se trata de un concepto que pretende poner en términos financieros cualquier carencia técnica de un producto.
En el caso que nos ocupa, la deuda técnica se define como el coste de desarrollo para eliminar los riesgos debidos a la calidad de código en un entorno productivo. Adicionalmente, podemos incluir:
- El coste asociado a la complejidad,
- La falta de documentación,
- Difícil testabilidad etc.,
Según las herramientas de análisis que se utilicen, la deuda técnica puede venir dada en jornadas o en un valor monetario. Independientemente de cómo se exprese, el cálculo se realiza en base a los siguientes factores:
- Asignación de un tiempo de corrección a cada incumplimiento de cada regla.
- Ponderación de dicho tiempo con un factor de complejidad asociado al elemento en el que se produce el incumplimiento.
De esta forma, dos incumplimientos de la misma regla resultarán más costosos de corregir según la complejidad del objeto en el que se producen.
Por Francisco Manuel López
Jefe de Proyecto QA en MTP