Análisis de Código. Asegurar la calidad del código, un primer paso hacía la mejora de la calidad global del software

Transcripción

1 Análisis de Código Asegurar la calidad del código, un primer paso hacía la mejora de la calidad global del software

2 Indice Por qué el análisis de código? Errores comunes en Ingeniería de Software Tipos de análisis de código Análisis Estático Análisis Dinámico Análisis desde el punto de vista de: Calidad Capacidad Seguridad Herramientas Casos Prácticos

3 Razones para el análisis de código El análisis de código es un medio que nos permite mejorar, no es un fin en si mismo. Permite validar las reglas metodológicas aplicadas en el proyecto. La detección de incidencias, permiten la adecuada localización de errores que pasan desapercibidos en el ciclo de desarrollo. Partiendo de una metodología adecuada, y usando el análisis de código como un apoyo a la calidad. El análisis de código, facilita con una minima inversión de tiempo, la localización de "defectos" permitiendo un alto grado de retorno de inversión. El análisis manual, por su coste deberá ser abordado en fases críticas de proyectos de desarrollo de software o en proyectos críticos. El análisis automático, puede ser realizado con una mayor periodicidad ya que no requiere de intervención y puede ser programado y repetido tantas veces como sea necesario, dotando el proyecto de un mecanismo ágil de validación y certificación.

4 Errores comunes en Ingeniería de Software Existen algunos errores, comunes en ingeniería de software, que sugieren abordar el análisis de código: Existe la creencia de que cualquier persona que pueda escribir software puede escribir buen software. También existe una creencia errónea de que la ejecución de algunos casos de prueba representativos indica que el software es "correcto" o adecuado. No valorar el impacto de los cambios al software y, en particular permitir cambios innecesarios, sin control. No valor el impacto del cambio en su futuro y validez, no valorar su correcto funcionamiento. No entender que la realización de un buen diseño es más importante que la producción de grandes cantidades de código. Que el objetivo de la ingeniería de software es no sólo para producir el código, sino también para producir soluciones fiables.

5 Tipos de análisis de código Se han establecido dos categorías: Analisis Estático El análisis estático de código consiste en el análisis de un sistema informático mediante la inspección directa de la fuente u objeto codificada que describe el sistema con respecto a la semántica del código (sin ejecución del/los programa/s, como en el análisis dinámico). La experiencia demuestra que muchos de los planteamientos que la industria considera demasiado costoso (como la especificación formal y el análisis estático de código) en realidad puede reducir y reducen el coste total. Análisis Dinámico Consiste en el análisis de las aplicaciones informáticas, mediante la ejecución de los programas en un procesador real o virtual. Para el análisis dinámico pueda ser eficaz, deberá ser ejecutado con un conjunto de entradas de prueba suficientes para producir un comportamiento interesante. Permite la obtención de métricas tales, como cobertura de código, niveles de ejecución.

6 Análisis desde diferentes puntos de vista Calidad Asegurar el cumplimiento de los estándares del proyecto. Asegurar el cumplimiento de los estándares de desarrollo, que permiten asegurar el correcto cumplimiento de las métricas del proyecto. Identificación de áreas problemáticas Identificación de problemas de gestión Capacidad Dimensionamiento de sistemas Rendimiento de sistemas bajo desarrollo Rendimiento de capacidades humanas Código de terceros Seguridad Es el método más adecuado de encontrar los defectos de seguridad, siendo el primer beneficio del análisis del código. Permite identificar necesidades de análisis detallados, justificando las inversiones. Debería realizarse como auditoria, de forma periódica. Permite validar la adhesión a los estándares.

7 Como proceder con el Análisis de Código Existen diferentes mecanismos y técnicas, algunas de las cuales vamos a comentar en esta presentación. Principalmente independientemente de la técnica debemos centrarnos en: Reducir los falsos positivos Identificar y parametrizar en base al ámbito de aplicación Realimentar las herramientas, procesos con los resultados Proceso de cambio continuo, evolución.

8 Ámbito de aplicación Áreas de análisis, en revisión manual de código: Aspectos del diseño de la API Otros aspectos de la arquitectura (como la elección de enlaces de cliente y la herencia ) La elección de estructuras de datos y algoritmos Estilo de Programación Comentarios y documentación La adherencia a prácticas de codificación oficial

9 Ámbito de aplicación La elección de las abstracciones es una cuestión clave en la programación con diseño orientado a objetos. Los desarrolladores deben discutir si una cierta clase está realmente justificada o deba pasar sus funcionalidades a otra, o, por el contrario, si una potencial clase se ha perdido. El diseño de las API o interfaces del software es esencial para su uso por otros elementos de software y permitir su reutilización. Debemos velar por el cumplimiento del DISEÑO del API y de forma sistemática hacer un fuerte énfasis en la coherencia del software como un todo.

10 Combinar Análisis Estático y Dinámico La solidez y la integridad son dos de las principales preocupaciones de una herramienta de análisis estático para encontrar defectos en el software. Un análisis comparativo estático del programa a través de todos los caminos no siempre es posible, especialmente para un software complejo. Además, unas pruebas exhaustivas para detectar todos los errores son imposibles de realizar. A continuación se describen una técnica que utiliza los datos de cobertura de las pruebas para eliminar rutas de prueba y luego analiza la forma estática el resto del código. Mediante la reducción de los caminos de análisis se permite realizar un análisis completo mediante prueba estática, de esa forma podemos realizar un análisis más detallado de un conjuto reducido de código, mejorando así la eficacia.

11 Combinar Análisis Estático y Dinámico Una aproximación interesante al análisis de código parte de la combinación de ambos métodos, permitiendo una reducción de los tiempos de análisis y mejorando: Los falsos negativos El foco del análisis en las áreas de riesgo Partiendo de un análisis dinámico establecemos un valor mínimo de cobertura (umbral), que nos indique que por debajo de ese umbral nos encontramos en un área de riesgo. Identificadas las partes del programa con áreas de riesgo procedemos a realizar un análisis estático de las mismas. El foco del análisis se centra en las áreas del código que no se han cubierto con el análisis dinámico, y con el conjunto de entradas del mismo.

12 Combinar Análisis Estático y Dinámico Se pueden analizar mejor los caminos con poca posibilidad de test. El esfuerzo de la prueba es aprovechado para un mejor análisis estático. El tiempo de ejecución de análisis estático se reduce. El número de alertas emitidas, así como el ruido se reduce permitiendo detectar mejor errores graves, Esto redunda en que el esfuerzo de test sea más útil, práctico y focalizado.

13 Detección mediante patrones de Error Esta técnica en términos generales, consiste en crear patrones para cada tipo de defecto, que se pueden agrupar en las siguientes categorías: La corrección de un único thread La correcta sincronización entre threads Problemas de rendimiento Problemas de Seguridad Problemas de vulnerabilidad Definiendo y cargando patrones de error, podemos identificar estos errores en grandes conjuntos de código, donde participan múltiples desarrolladores.

14 Herramientas Análisis Estático Data Flow Metrics Análisis Dinámico Test automation, test cases interaction and evaluation Peer code Review process automation preparation, notification, and tracking Unit testing unit test creation, execution, optimization, and maintenance Runtime error detection memory access errors, leaks, corruptions, and more

15 Herramientas Fundamentos básicos de las herramientas de análisis Diseño inicial partiendo de experiencia en campo Adaptación de las herramientas mediante parametrización Énfasis en el análisis de alarmas Estructura de los analizadores Fase de preprocesado Fase de análisis Interacción en la estructura general Interacción en las primitivas Aproximación a las reglas. Dominios Dominio basado en Memoria Dominio basado en Aritmética Dominio basado en Algorítmica

16 Herramientas LLVM - CLANG: Partiendo de las herramientas LLVM y CLANG en su versión 2.0 (trunk 104xxx) Permiten análisis estático de código en tiempo de compilación. CCCC-Prime Versión modificada que permite la generación de tabla de dependencias para: análisis gráficas trazabilidad API-sanity-autotest Versión modificada que permite la generación de test automáticos partiendo de las librerías, generando las pruebas de validación y entrada. Creación de pruebas unitarias automáticas. OSEE Versión modificada, permite la gestión de pruebas, generación y seguimiento de pruebas, análisis estático.

17 Casos prácticos Ejemplo de análisis estático Un análisis con una versión personalizada de llvm-clang nos remite el siguiente problema: myapertura(remoteipaddress); warning invalid conversion from char to bool El valor de remoteipaddress (" ") es tomado como bool ( "1" ) en vez de como una cadena. Este error ha motivado que se dedique una semana/hombre a identificar por que un sistema no se comportaba correctamente al realizar un cambio de rango de direcciones. Coste 300 día *5 días= 1500.

18 Casos prácticos En un gran proyecto, la funcionalidad del módulo de informes, imprescindible para el usuario, se retrasaba por que el acceso al módulo se hacia muy lento. En Desarrollo y pruebas este problema no se detectaba. Un análisis visual del código, peer-review, identifico el problema, el acceso se realizaba validando los usuarios de forma secuencial, en pruebas el listado de usuarios contenía 10 filas, en producción El diseño no contemplaba esta circunstancia y el acceso se realizaba de forma secuencial en un fichero de texto plano. El análisis visual llevó una hora de trabajo, el tiempo invertido anteriormente fue el equivalente a 12 meses/hombre.

19 Contacto Roberto Cruz Pérez Parque Empresarial Las Mercedes Campezo, 2 Edif. 7 2ª Planta MADRID