inspección y evaluación de calidad de producto software... talk is cheap, show me the code!

14/11/2014

SeminariosMiércoles 12 de Noviembre de 2014

INSPECCIÓN Y EVALUACIÓN DE LACALIDAD DE PRODUCTO SOFTWARETALK IS CHEAP, SHOW ME THE CODE

Antonio Calero, Jesús BadenasÁrea de Innovación, Arquitectura y Calidad de Software

14/11/2014

12 y 13 de noviembre de 2014 Valencia, España 3

Agenda

Introducción a la calidad de producto software

Medición y evaluación

Herramientas de soporte

Ejemplos prácticos

INTRODUCCIÓN YCONCEPTOS BÁSICOS

¿Qué es la calidad de producto software y por qué tenemos que evaluarla?

14/11/2014

proceso

equipo producto

proceso

equipo producto

14/11/2014

la calidad del proceso no garantiza la calidad del producto software

14/11/2014

las buenas prácticas ITIL/ISO 20000 no aseguran la calidad del producto

14/11/2014

La mala calidad de producto siempre tiene un coste

La mala calidad se puede detectar y medir

14/11/2014

MEDICIÓN Y EVALUACIÓN Los pecados capitales del desarrollo de software

14/11/2014

“Si algo puede ser medido y expresado con números, entonces es que se sabe algo acerca de eso”

Lord Kelvin Thompson

“Lo que no se puede definir, no se puede medir, lo que no se puede medir no se puede mejorar, y lo que no se puede mejorar se deteriora siempre”

¿Por qué medir?

14/11/2014

Número de líneas físicas

Número de líneas reales

Número de clases

Número de paquetes

Número de métodos

Número de gets/sets

Número de sentencias

Número de APIs públicas

Tamaño del entregable

• Seguimiento y evolución del proyecto• Complejidad en términos muy

generales• Si se relaciona con métricas de gestión

puede dar información relevante como:

• Número de errores por líneas de código

• Número de líneas de código por requisito

• Número de líneas de código por desarrollador

El tamaño

• Facilita el mantenimiento• Independencia del desarrollador• Mantener las APIs públicas

documentadas es muy importante porque es código susceptible de ser utilizado por otros desarrolladores

• No deberían nunca existir líneas de código comentadas

Número total de líneas con comentarios

Líneas de código comentadas

Densidad de comentarios

APIs públicas no documentadas

Porcentaje de APIs públicas documentadas

La densidad de comentarios

14/11/2014

• Cut and Paste Detection• Dificulta el mantenimiento• Aumenta el tamaño

innecesariamente• Es indicativo de malas prácticas• Produce un efecto bola de nieve

Bloques de código duplicado

Líneas de código duplicadas

Ficheros con código duplicado

Porcentaje de código duplicado

El código duplicado

¡CUESTIÓN DE PRINCIPIOS!

DRY – Don’t Repeat YourselfDIE – Duplication Is Evil

"Every piece of knowledge must have a single, unambiguous, authoritative representation within asystem.“

• Complejidad ciclomática o índice McCabe

• Mide el número de caminos de ejecución diferentes

• Cuantos más caminos, más difícil de probar, más difícil de entender

• Es interesante estudiar la distribución de la complejidad en los proyectos

Complejidad por método

Complejidad por clase

Complejidad total

La complejidad

14/11/2014

• Permite identificar problemas de complejidad a un nivel mayor que en método o un fichero

• Ciclos entre clases y paquetes• Identifica un alto acoplamiento y

baja cohesión

Ciclos

Dependencias entre paquetes

Dependencias entre ficheros

El diseño

• La cobertura determina como de buenas son las pruebas unitarias

• A mayor cantidad de cobertura mayor cantidad de código está sometido a las pruebas

• El 20% del código contiene la funcionalidad más crítica. Ese código debería estar probado al 100%

• Si un desarrollador no hace pruebas unitarias, ¿con qué derecho pide que se hagan pruebas funcionales?

Porcentaje de cobertura de código

Cobertura de líneas

Cobertura de ramas

Porcentaje de éxito en las pruebas unitarias

Número de fallos

Número de errores

Número de tests

Duración de los tests

Las pruebas unitarias

14/11/2014

• Se definen la normativa de desarrollo con los patrones y estándares a seguir por todos los desarrolladores

• El conjunto de buenas prácticas a cumplir define el nivel de exigencia

• Cada patrón o regla se fija con un nivel de prioridad y un peso específico:

• Bloqueante (10)

• Crítica (5)

• Mayor (3)

• Menor (1)

• Informativo (0)

El cumplimiento de estándares

“A well-written program is a program

where the cost of implementing a

feature is constant throughout the program’s lifetime.”

Itay Maman

La deuda técnica

14/11/2014

HERRAMIENTAS DESOPORTE

¿Con qué armas contamos para evaluar el producto software?

14/11/2014


Herramientas de inspección

Analizan el código fuente en busca de errores y malas prácticas


Herramientas de inspección

Vale, pero… ¿Y si queremos agruparlo todo?

14/11/2014


SonarQube: análisis

1.Descarga del código fuente

1.Compilación

1.Inspección de código

1.Interpretación de resultados


SonarQube: análisis

14/11/2014

EJEMPLOS PRÁCTICOS Talk is cheap, show me thecode!


¿Alguna pregunta?

14/11/2014


Antonio Calero, Jesús BadenasÁrea de Innovación, Arquitectura y Calidad

partner oficial en latinoaméricapartner exclusivo en España