Este documento presenta una charla sobre inspección y evaluación de la calidad de producto software. La charla cubre conceptos básicos de calidad de producto, métricas para medir la calidad como tamaño de código, duplicación, complejidad y pruebas unitarias. También se discuten herramientas para evaluar el código como SonarQube y se muestran ejemplos prácticos.

1. 14/11/2014
Seminarios
Miércoles 12 de Noviembre de 2014
INSPECCIÓN Y EVALUACIÓN DE LA
CALIDAD DE PRODUCTO SOFTWARE
TALK IS CHEAP, SHOW ME THE CODE
Antonio Calero, Jesús Badenas
Área de Innovación, Arquitectura y Calidad de Software

2. 14/11/2014
Agenda
 Introducción a la calidad de producto software
 Medición y evaluación
 Herramientas de soporte
 Ejemplos prácticos
12 y 13 de noviembre de 2014 Valencia, España 3
INTRODUCCIÓN Y
CONCEPTOS BÁSICOS
¿Qué es la calidad de
producto software y por
qué tenemos que
evaluarla?

3. 14/11/2014
proceso
equipo producto
proceso
equipo producto

4. 14/11/2014
la calidad del proceso no garantiza la calidad del
producto software

5. 14/11/2014
las buenas prácticas ITIL/ISO 20000 no aseguran la calidad
del producto

6. 14/11/2014
La mala calidad de producto siempre tiene un coste
La mala calidad se puede detectar y medir

7. 14/11/2014
MEDICIÓN Y EVALUACIÓN Los pecados capitales del
desarrollo de software

8. 14/11/2014
“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”
“Si algo puede ser medido y expresado con números,
entonces es que se sabe algo acerca de eso”
Lord Kelvin Thompson
¿Por qué medir?

9. 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
El tamaño
• 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
• 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

10. 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 Yourself
DIE – Duplication Is Evil
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a
system.“
• 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

11. 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

12. 14/11/2014
El cumplimiento de estándares
• 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)
“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

13. 14/11/2014
HERRAMIENTAS DE
SOPORTE
¿Con qué armas contamos
para evaluar el producto
software?

14. 14/11/2014
Herramientas de inspección
Analizan el código fuente en busca de errores y malas prácticas
12 y 13 de noviembre de 2014 Valencia, España 27
Herramientas de inspección
Vale, pero… ¿Y si queremos agruparlo todo?
12 y 13 de noviembre de 2014 Valencia, España 28

15. 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
12 y 13 de noviembre de 2014 Valencia, España 29
SonarQube: análisis
12 y 13 de noviembre de 2014 Valencia, España 30

16. 14/11/2014
EJEMPLOS PRÁCTICOS Talk is cheap, show me the
code!
¿Alguna pregunta?
12 y 13 de noviembre de 2014 Valencia, España 32

17. 14/11/2014
Antonio Calero, Jesús Badenas
Área de Innovación, Arquitectura y Calidad
partner oficial en latinoamérica
partner exclusivo en España
12 y 13 de noviembre de 2014 Valencia, España 33