He recibido algún material de Capers Jones, autor bien conocido y conferenciante internacional (no es necesario presentarle, pero por si acaso: http://www.namcook.com/aboutus.html). Capers Jones es vicepresidente y director de tecnología (CTO) de Namcook Analytics LLC.

Es una buena síntesis del estado actual de la calidad del software, por lo que acabo de hacer un resumen de los puntos principales, que nos da la oportunidad de hacer algunas preguntas a Capers.

Introducción

En 2012, más de la mitad de los proyectos de software por encima de 10 000 Puntos de Función o Function Points (alrededor de 1 000 000 líneas de código) se cancelan o se retrasen por más de un año. La siguiente tabla muestra los resultados de 13 000 proyectos clasificados en seis tamaños diferentes, y los porcentajes de los que están a tiempo, temprano, tarde o cancelado.

Table 1: Software Project Outcomes By Size of Project

	Early	On-Time	Delayed	Canceled
1 FP	14.68%	83.16%	1.92%	0.25%
10 FP	11.08%	81.25%	5.67%	2.00%
100 FP	6.06%	74.77%	11.83%	7.33%
1 000 FP	1.24%	60.76%	17.67%	20.33%
10 000 FP	0.14%	28.03%	23.83%	48.00%
100 000 FP	0.00%	13.67%	21.33%	65.00%
Average	5.53%	56.94%	13.71%	23.82%

Q: ¿Cómo ha conseguido todos estos datos sobre todos estos proyectos? ¿Son todos de EE.UU.?

He trabajado en IBM y ITT y tenía acceso a todos sus datos internos. También tenía un equipo de una docena de consultores que traen los datos de 25 a 75 proyectos por mes a partir de cientos de empresas. He trabajado en 24 países, pero alrededor del 90% de los datos de la tabla es de los EE.UU.

Los mejores países para la calidad son Japón y la India. Productividad es algo más complejo debido a enormes variaciones en las horas de trabajo. En los EE.UU. tenemos una semana nominal de 40 horas, de 44 horas en Japón, sólo 36 horas en Canadá. También hay diferencias importantes en las vacaciones y los días festivos. Esto es demasiado complicado para una respuesta rápida.

Q: Usted dice que 10 000 FP es de aproximadamente 1 000 000 líneas de código. ¿Es esta una medida que alguien puede utilizar para comparar sus proyectos con estos datos, cuando no tiene estimación de FP? ¿O hay alguna otra medida como, por ejemplo, el tamaño del equipo de desarrollo, el número de años/hombre?

La proporción de tratamientos de código respecto a un punto de función se llama “backfiring” y fue desarrollado por primera vez en los años 70 por IBM. La proporción varía según el lenguaje o la combinación de tecnologías. COBOL es aproximadamente 105,7 sentencias por punto de función; C es de unos 128 declaraciones por punto de función, Java es cerca de 53 sentencias por punto de función. Varias compañías venden listas de esos ratios para 1000 lenguajes de programación.

Volumen de defectos

Al examinar los proyectos con problemas de software, la principal razón de demora o de cancelación se debe a un volumen excesivo de defectos graves. La tabla 2 muestra los volúmenes promedio de defectos encontrados en los proyectos de software, y el porcentaje de defectos removidos antes de la entrega a los clientes, por diferentes orígenes.

Table 2: Defect Removal Efficiency By Origin of Defects Circa 2012

Defect Origins	Defect potentials	Removal Efficiency	Delivered Defects
Requirements	1.00	77%	0.23
Design	1.25	85%	0.19
Coding	1.75	95%	0.09
Document	0.60	80%	0.12
Bad Fixes	0.40	70%	0.12
Total	5.00	85%	0.75

(Datos en defectos por Function Point)

Q: Podemos ver en la tabla anterior que los potenciales defectos de código son por encima de los otros. ¿Respecto a eso, ha visto usted una evolución entre las diferentes tecnologías utilizadas en los proyectos? Mucha gente piensa que las nuevas tecnologías, porque más complejas, son más propensas a introducir defectos?

Defectos de código están principalmente relacionados con el nivel de tecnologías utilizadas. Cada fuente de defectos se ve afectada por la complejidad, y aplicaciones multi-capas como cliente-servidor tienen más defectos de diseño y de requisitos.

Q: Podemos ver también que defectos de requisitos y de diseño son más numerosos que los defectos de código. La misma pregunta: ¿ha visto allí cualquier evolución? Con el énfasis puesto en la externalización y el outsourcing, se podría pensar que esos defectos suceden más y más frecuentes.

Existen herramientas eficaces, como Flesch y FOG, de análisis de texto o de UML que pueden reducir los defectos de requisitos. También de modelización de requisitos y de ‘pattern matching’. Usuarios Agile integrados pueden ayudar también, pero con límites. Un solo usuario no puede entender todas las funcionalidades de una aplicación de 10 000 puntos de función o de 10 000 usuarios.

La industria del software debería utilizar métodos de requisitos y de diseño en 3D – no sólo diagramas de texto y estáticos. Si utilizas métodos adecuados, tienes alta calidad y plazos cortos al mismo tiempo.

De hacer un trabajo pericial en juicios sobre los proyectos que fracasan, la mayor parte falla debido a un pobre control de cambios y de calidad. Demasiados bugs antes de la fase de QA extienden los ciclos de prueba de una manera casi infinita.

Dos estrategias se necesitan para un control de calidad con exito:

1. La reducción de los volúmenes de defectos y defectos potenciales.
2. El aumento de la eficiencia de eliminación de defectos (Defect Removal Efficiency o DRE). Podemos notar que DRE no es muy bueno para los defectos que no son de código.

Reducción de volumenes de defectos

Algunos de los métodos que reducen defectos incluyen:

• Modelización de requisitos.
• Herramientas de análisis estático de requisitos que pueden encontrar errores y ambigüedades.
• Requisitos formalizados y inspecciones de diseño.
• Usuarios incorporados, como se encuentra en desarrollo Agile.
• Desarrollo basado en prueba, cuando diseño está precedido por la definición de las pruebas.
• Prototipos para minimizar los cambios de requisitos.
• Revisión formal de todas las solicitudes de cambio (Change Requests).
• Herramientas automatizadas de control de cambios con capacidades de referencias cruzadas.

Cuando inspecciones formales se añaden al ciclo de desarrollo, los potenciales defectos gradualmente se reducen de 5 por punto de función por debajo de 3 por punto de función, mientras que los niveles de eficiencia de eliminación de defectos (DRE) llegan al 95% y hasta pueden alcanzar 99%.

Análisis de código es una forma relativamente nueva de eliminar defectos, que también tiene beneficios en términos de prevención de defectos.

Un aspecto interesante del control de los requisitos es la reducción de los cambios no planificados o “requirements creep”. Proyectos donde los requisitos son cuidadosamente recogidos y analizados consiguen sólo una fracción de 1% por mes en los cambios planificados. Joint Application Design (JAD), prototipos, y inspecciones de requisitos son efectivos en la reducción de “requirements creep”.

Aumentar los niveles de eficiencia de eliminación de defectos (DRE)

Muchas formas de pruebas realizadas por los desarrolladores tienen menos de 35% de eficiencia en la búsqueda de errores o defectos, aunque unos superan 50%. QA con pruebas formalizadas y con personal certificado es por lo general con frecuencia por encima de 50%.

Diseño formal e inspecciones de código superan 65% de eficiencia en la búsqueda de errores o defectos y a veces 85%. Las inspecciones también aumentan la eficiencia al proporcionar pruebas más completas para el personal de la prueba.

El análisis de código es también alto en eficiencia contra muchos tipos de defectos. Por lo tanto, todos los proyectos en empresas líderes utilizan combinaciones sinérgicas de inspecciones formales, análisis de código y QA.

Esta combinación es la única forma conocida de conseguir niveles de eliminación de defectos superiores a 98%, permite plazos de desarrollo más cortos y reduce las probabilidades de errores en los proyectos.

Q: En los métodos anteriores, algunos son automatizados y podría ser más barato, otros – como el diseño formalizado e inspecciones de código – no pueden automatizarse, y por lo tanto son probablemente más caro. ¿Alguna vez ha tratado de definir una relación entre el costo y la eficiencia de estos métodos?

Usted se equivoca. Antes de que IBM introdujo inspecciones para el desarrollo de una base de datos, la fase de QA necesitaba 3 meses de pruebas. Después inspecciones, la fase de pruebas se redujo a 1 mes. Las inspecciones ncesitaron cerca de 6 semanas. Hubo una reducción en los costos y los plazos y un aumento en la eficiencia de eliminación de defectos, que estaba por debajo de 85% hasta más del 95%, al mismo tiempo.

Su pregunta refleja un problema común – la mayoría de las empresas no miden lo suficiente como para entender la economía de la calidad. Tengo datos sobre los costes comparativos de cada combinación de inspecciones, análisis de código y pruebas. Los mejores resultados se obtienen con una combinación sinérgica de la prevención de defectos, eliminación de defectos preliminarios y pruebas realizadas por personal certificados.

Q: ¿La eficacia de estos métodos varía dependiendo del tamaño de un proyecto? Uno puede pensar instintivamente que cuanto mayor sea el proyecto, mayor será el riesgo de encontrar defectos de diseño y de requisitos, mientras que los defectos de código deben permanecer (más o menos) estable?

Cuando las aplicaciones crecen en tamaño, los defectos potenciales se hacen más importantes y la eficiencia de eliminación de los defectos disminuye. Es por eso que inspecciones y análisis de código son más valiosos cuando las aplicaciones se hacen más grandes.

Q: Yo diría que para los proyectos grandes, se recomienda industrializar todos estos métodos. Sin embargo, para proyectos más pequeños o de tamaño medio, o para un equipo que todavia no utiliza estos métodos, le recomendaría algunos que consideraría más fácil o más valioso para poner en práctica por primera vez? Para decirlo de otro modo, ¿hay un mejor camino hacia la madurez?

Esto es una pregunta demasiada complicada para una respuesta corta. El análisis de código es barato, eficaz y fácil de usar para todos los proyectos de todos tamaños. Por debajo de 1 000 puntos de función, Agile está bien, por encima de los 10 000 puntos de función, TSP es lo mejor.

Lo que las empresas necesitan no son respuestas generales, pero predicciones específicas y un conjunto de métodos óptimos para proyectos específicos. Mi trabajo principal es la construcción de herramientas que permitan predecir los resultados específicos para proyectos concretos.

Q: Una última pregunta, para concluir, y probablemente una acerca de la cual la mayoría de las personas sienten curiosidad: ¿qué es un día típico para usted? Haciendo consultoría para un cliente? Trabajo sobre un papel o un nuevo libro? Ir a pescar o jugar al golf?

Hace años, cuando yo estaba trabajando en mi primer libro, yo tenía que estar en el trabajo a las 8:30 así que empecé a levantarme temprano para escribir a las 5 de la mañana. Después de 15 libros, no puedo dormir tarde. Yo suelo escribir libros o artículos entre las 4 y las 10 AM., cambiar a tareas de software o de negocios desde las 10 AM hasta las 4 PM, y luego relajarme o jugar al golf después. También hago desporte en un gimnasio tres días a la semana.

Gran parte de mis consultorías y discursos también son remotos. El 08 de noviembre estaré en una conferencia en Estocolmo, Suecia. El tema es “Achieving Software Excellence”. El 13 de noviembre, estoy haciendo un seminario sobre “Software Risk and Value Analysis”. El 4 de diciembre, un webcast de IBM sobre “Measuring Software Quality and Customer Satisfaction”.

Hago viajes a conferencias más importantes, como para el Symposium japonés on Software Testing, the Malaysian Testing Conferenc, y conferencias para el International Function Point Users Group.

Capers, muchas gracias por el material que me ha enviado y por el tiempo para responder a mis preguntas.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.