El libro consta de los siguientes capítulos:

• 1 CALIDAD DEL PRODUCTO SOFTWARE, TU EMPRESA TENDRÁ UN PROBLEMA SI NO SE PREOCUPA POR ELLA.
• 1.1.Dimensiones de la calidad del software
• 1.1.1 La calidad del proceso
• 1.1.2 La calidad del producto
• 1.1.3 La calidad del equipo y/o personas
• 1.1.4 ¿Qué perspectiva de calidad es más importante?
• 1.2 Razones por las que la calidad del producto software debería preocuparte mucho.
• 1.2.1 Calidad del producto no es lo mismo que testing
• 1.2.2 La calidad del proceso no garantiza la calidad del producto
• 1.2.3 La mala calidad del producto siempre tiene un coste
• 1.2.4 El cliente puede detectar la mala calidad del producto software
• 1.2.5 las buenas prácticas no aseguran calidad del producto
• 2 MODELOS Y ESTÁNDARES DE CALIDAD DEL PRODUCTO SOFTWARE
• 2.1 La norma ISO 9126
• 2.1.1 La mantenibilidad en ISO 9126
• 2.2 La norma ISO 25000 (SQUARE)
• 2.2.1 Estado de la iso 25000
• 2.3 Cambios entre la ISO 9126 y la ISO 25000
• 2.4 El estándar de calidad de producto de CISQ
• 2.4.1 ¿Qué características contempla?
• 3 MÉTRICAS: MIDIENDO LA CALIDAD DEL PRODUCTO SOFTWARE
• 3.1 ¿Calidad del producto en código o en “papel”?
• 3.2 ¿Qué es una métrica?
• 3.3 Métricas imprescindibles: Complejidad ciclomática y código reptido
• 3.3.1 Código repetido
• 3.3.2 Complejidad ciclomática
• 3.4 Valores umbrales aconsejados
• 3.4.1 Valores de calidad software de 51 aplicaciones de Github
• 3.5 Otras métricas
• 3.5.1 Número de líneas de código
• 3.5.2 Porcentaje de comentarios
• 3.5.3 Dependencias cíclicas
• 3.5.4 Cobertura de pruebas unitarias
• 3.5.5 Más métricas
• 3.6 Típicas excusas a la hora de implantar métricas de calidad
• 3.6.1 “Al comenzar el proyecto, yo no sabía los umbrales que deberían tener las métricas, por eso no pusimos un valor objetivo”
• 3.6.2 “Preferimos ver como avanza el proyecto y ahí poner objetivos”
• 3.6.3 “Es que hay veces, en la práctica, que hay que saltarse alguna métrica”
• 3.6.4 “Es que hay muchas métricas, reglas, etc., y no me voy a poder poner a mirar todo”.
• 3.7 Algunos consejos sobre la implantación de métricas software
• 3.7.1 Empieza con pocas métricas y que estas ayuden al negocio.
• 3.7.2 Mide en periodos cortos, frecuentemente y de manera automatizada
• 3.7.3 Define niveles de abstracción.
• 4 OTRAS MALAS PRÁCTICAS
• 4.1 Malos olores
• 4.2 Exceso de patrones de diseño
• 4.3 Falta de encapsulación
• 4.4 Reglas de diseño de micro arquitecturas OO
• 4.4.1 Regla de si hay dependencias de clases concretas
• 4.4.2 Regla de si un objeto tiene diferente comportamiento según su estado
• 4.4.3 Regla de si una jerarquía de clases tiene muchos niveles
• 4.4.4 Regla de si algo se utiliza muy poco o no se utiliza
• 4.4.5 Regla de si una súper clase conoce a alguna de sus subclases
• 4.4.6 Regla de si una clase colabora con muchas
• 4.4.7 Regla de si un cambio en una interfaz impacta en muchos clientes
• 4.4.8 Regla de si entre una interfaz y su implementación no hay una abstracción
• 4.4.9 Regla de si una súper-clase es concreta
• 4.4.10 Regla de si un servicio tiene muchos parámetros
• 4.4.11 Regla de si una clase es grande
• 4.4.12 Regla de si elementos de interfaz de usuario están en entidades de dominio
• 4.4.13 Regla de si una clase utiliza más cosas de otra que de sí misma
• 4.4.14 Regla del si una clase rechaza algo de lo que hereda
• 4.4.15 Regla de si los atributos de una clase son públicos o protegidos
• 5 REFACTORIZACIÓN
• 5.1 ¿Por qué refactorizar?
• 5.2 Aplicación
• 5.3 Invertir en mejorar la clase con peores métricas de calidad puede ser un error
• 6 HERRAMIENTAS DE CALIDAD DE PRODUCTO SOFTWARE
• 6.1 Las herramientas de calidad de código no son suficientes
• 6.2 Automatización
• 7 REFERENCIAS