AventiaNews Enero 2013
28/10/2011 |
Estoy en busca de mejores métodos de control de calidad, mejores herramientas de cálculo y recojo datos cuantitativos fiables sobre la productividad y la calidad (del software)
Capers Jones, asesor del Consorcio de Calidad del Software de Tecnologías de la Información (CISQ)
Capers_Jones
Wikipedia dice de usted: “Capers Jones es un especialista en metodologías de ingeniería del software a menudo asociado con el modelo de estimación de costes de puntos de función. Él colecciona datos sobre calidad del software, riesgos y mejores prácticas”. Mi primera pregunta es: ¿Cómo se define usted mismo y cuál considera que es su contribución a la industria de la ingeniería del software?

En los años 70’ fui se me encargó reunir información cuantitativa sobre productividad y calidad en IBM. Los datos fueron interesantes y disfruté recopilando esa información, por lo que nunca dejé de hacerlo. Después de 40 años de recopilación de información tengo información sobre 13,000 proyectos de software. Recopilé información interna cuando trabajé en IBM e ITT. Después de fundar Software Productivity Research (SPR) en 1984 mi equipo y yo reunimos datos de alrededor de más de 650 compañías en 24 países.


En Aventia utilizamos sus métricas y modelos predictivos para construir una base de gestión cuantitativa de los procesos de construcción y pruebas de software. Las métricas que usted publica son muy concretas. ¿Cómo obtiene usted estas métricas y que nivel de confianza podemos depositar en ellas?

En 1984 desarrollé un cuestionario para recopilar tanto información de evaluación como información cuantitativa sobre calidad y productividad. El cuestionario fue desarrollado un año antes que el del Software Engineering Insitute (SEI), por lo que he estado haciendo evaluaciones más tiempo que el SEI. A diferencia del SEI, yo recopilo información cuantitativa sobre la calidad y productividad además de datos de evaluación cualitativos.

Durante unos 15 años hasta que vendí SPR y me retiré en el 2000 tuve más de una docena de consultores en la recopilación de datos entre 25 y 75 proyectos cada mes. SPR todavía recoge estos datos aunque ahora ya estoy jubilado y no formo parte de la compañía.

Tanto SEI como yo usamos preguntas de evaluación, pero mis cuestiones tienen una estructura diferente. Mis preguntas tienen una escala de cinco puntos y un “1” es el mejor. Con SEI, “5” es el mejor. Mis preguntas se parecen a lo siguiente:

EXPERIENCIA EN PROJECT MANAGEMENT
1. Experto (muchos proyectos importantes implementados)
2. Amplia (algunos proyectos importantes implementados)
3. Normal (al menos un proyecto importantes implementado)
4. Limitada (participación en proyectos importantes pero sin dirigirlos)
5. Debutante (sin experiencia ni dirección de proyectos importantes)

Debido a que el 3 representa la media aproximada en EEUU, es fácil mostrar a los clientes como se comparan co la media estadounidense.

En total tengo alrededor de 375 preguntas y también recojo información cuantitativa sobre productividad y calidad.

Tuve varios estadistas trabajando para mi, por lo que la exactitud de los datos históricos tienen un margen de error del 5%. De hecho, uno de los beneficios de la recogida de datos in situ, como hicieron mis consultores, fue corregir errores de datos históricos.

Un error muy común es que las compañías no registran las horas extras no remuneradas. Otro error común es que no se registran los esfuerzos del Project Management.


Muchas de sus métricas están referenciadas a puntos de función. En España esta técnica no es muy utilizada y frecuentemente es criticada de ser lenta y difícil de entender, además de poco fiable. ¿Cómo podría usted animar a nuestro mercado a utilizarla y ganar confianza en ella? ¿Podría contarnos algunas experiencias positivas que promocionaran el uso extensivo de puntos de función en nuestro mercado?

La métrica de puntos de función es la métrica más utilizada en el mundo. El International Function Point Users Group (IFPUG) y el grupo de usuarios COSMIC tienen capítulos y filiales en 30 países.

Varios países como Brasil y Corea del Sur requieren que los puntos de función sean utilizados para todos los contratos del gobierno. Sé que algunas empresas españolas también utilizan puntos de función y, de hecho, se han desarrollado herramientas de conteo de puntos función.

En el pasado los puntos de función eran bastante caros de calcular. Un analista certificado de puntos de función cuenta a un ritmo de alrededor de 400 funciones por día. Ya que el "promedio" de un proyecto en puntos de función es de alrededor de 1.000 puntos, se tardaría más de dos días en contar un proyecto medio a mano.

Sin embargo, varias empresas e investigadores han desarrollado métodos mucho más rápidos. En enero, presenté una patente para un método de alta velocidad de conteo que puede producir tamaños utilizando los puntos de función y las declaraciones lógicas de código. El mismo método también se puede utilizar para contar 'story points' y puntos de casos de uso.

Mi método puede determinar el tamaño de un nuevo proyecto en alrededor de un minuto y 15 segundos. Se tarda aproximadamente un minuto y 35 segundos para determinar el tamaño de una aplicación legacy porque normalmente es necesario delimitar el tamaño de la aplicación i también de los evolutivos realizados. Esta determinación doble de tamaño toma unos segundos más.

Un método muy antiguo desarrollado en 1975 por el inventor de los puntos de función, Al Albrecht, se llamó "backfiring” – contraproducente-. Al y sus colegas de IBM midieron tamaño en puntos de función e instrucciones de código. Esto permitió que ellos y otros colegas publicaran datos sobre el número de instrucciones necesarias para implementar un punto de función.

Por ejemplo COBOL requirió alrededor de 106 instrucciones por punto de función en la procedure y data division. Hay catálogos que muestran el número de instrucciones de código fuente por punto de función de unos 800 lenguajes de programación. Para los nuevos lenguajes como Java, se necesitan unas 53 instrucciones par implementar un punto de función.


Al respecto del modelo operativo de desarrollo software estamos asistiendo a la irrupción de modelos ágiles frente a los tradicionales modelos de desarrollo en cascada. Nos gustaría saber si la aplicación de un modelo cuantitativo y predictivo tiene sentido con desarrollo ágil. ¿Cómo utilizar técnicas de puntos de función en estos escenarios ágiles?

Algunos proyectos Agile utilizan los puntos de función, pero muchos no miden nada de nada. Algunos de los proyectos Agile utilizan story points, pero estos no están definidos y no hay colecciones de datos de referencia para los stroy points así que no hay manera de comparar los proyectos de este tipo con puntos de referencia internacionales, tales como los recogidos por el Software Benchmark Standards Group (ISBSG).

Si se compara Agile con otras metodologías usando los puntos de función, verá que Agile es mucho mejor que el desarrollo en cascada, pero casi igual a otros métodos en cuanto a la productividad.

Los proyectos Agile raramente utilizan inspecciones de pre-test que son más eficaces que las pruebas, por lo que se quedan rezagados en control de calidad. Se necesita una combinación de inspecciones, análisis estático y pruebas formales para obtener más del 95% en la eficiencia total de la eliminación de defectos.


Desde el punto de vista de la ingeniería software, la gestión de la calidad de las aplicaciones es un aspecto clave, de hecho, su dimensión económica es el foco de su más reciente publicación “The economics of software quality”. ¿Qué argumentos de retorno económico podríamos utilizar para convencer a las organizaciones para que realicen una mayor inversión en calidad software?, ¿Qué guías al respecto podemos encontrar en su nuevo libro?

La industria del software es vergonzosamente mala en el control de calidad. La mayoría de las empresas no tienen ni idea de cómo medir la economía de la calidad. La métrica más común, el "coste por defecto" penaliza la calidad y alcanza sus mejores resultados para las aplicaciones que tienen muchos defectos. La métrica de "líneas de código" es tan mala para la medición de la calidad que me parece una mala práctica profesional. Las medidas de líneas de código ignoran los errores en los requisitos y el diseño, y también penalizan a los lenguajes modernos de alto nivel.

Si mides los costos de calidad, utilizando los puntos de función, encontrarás que hay una perfecta correlación entre los niveles de alta calidad, bajos costes, y plazos cortos. Los proyectos que superan el 95% de eficacia en eliminación de defectos, todos tienen calendarios más cortos y menores costes que los proyectos "medianos" que sólo eliminan el 85% de los errores.


Aventia está trabajando con importantes empresas en la definición de modelos de externalización de servicios de testing utilizando factorías. ¿Cuáles cree que son los retos tanto operativas como económicas de estas externalizaciones?, ¿qué benchmarking puede aportar su modelo de medidas a la actividad de software testing en general y a la gestión de factorías de pruebas en particular?

Como resultado de la medición de un número determinado de proyectos de outsourcing, hemos identificado que los mejores outsourcers son alrededor de un 10% mejor que sus clientes en términos de calidad y productividad.

Por supuesto que hay algunos proyectos de outsourcing que fracasan, pero en general la comunidad de empresas que realizan outsourcing es mejor que sus clientes. Esta es la razón por la que el outsourcing es una industria en crecimiento.

El Testing es un tema más complicado. Las empresas con la mejor calidad usan una combinación sinérgica de las inspecciones, análisis estático y pruebas formales.

Las mejores empresas de prueba también usan el personal de prueba certificado y desarrollan casos de prueba utilizando modelos matemáticos formales tales como los basados en el diseño de experimentos. También miden la cobertura de pruebas, la complejidad ciclomática, la eficiencia de eliminación de defectos, los errores en los casos de prueba en sí mismo, las malas correcciones o nuevos errores en los intentos de corregir los antiguos errores, entre otros.


Otro aspecto fundamental de la calidad del software es, sin duda, la definición y gestión de requisitos del software. A la vista de los informes del sector parece que no hemos mejorado grandemente en esta práctica. Nos gustaría saber cuál es, según su opinión, la situación de la industria al respecto de la definición y gestión de requisitos y qué métricas podría aportar su modelo a efectos de benchmarking.

Los requisitos de software son un eslabón débil en la cadena de las tecnologías de la ingeniería de software. Los requisitos están completos en menos de un 60%, contienen requisitos perjudiciales o "tóxicos" que no deben ser incluidos, y que crecen a más del 2% por mes de proyecto. Los requisitos son difíciles de entender.

En general los defectos de los requisitos no pueden ser encontrados y eliminados por la prueba. Sólo pueden ser encontrados y eliminados mediante el uso de las inspecciones formales. Los defectos de los requisitos se pueden prevenir mediante el uso de prototipos, diseño de la aplicación conjunta (JAD), y Quality Function Deployment (QFD). Sin embargo, no muchas empresas utilizan estos métodos.

También existen herramientas que pueden analizar las necesidades y encontrar errores. Éstas son similares a los análisis estáticos sólo que trabajan con texto. Hay otras herramientas que pueden calcular la legibilidad de los requisitos mediante el índice FOG u otras puntuaciones de legibilidad.

En general, los requisitos son problemáticos y la mayoría de las empresas no son muy buenas en su manejo.


Por último, ¿Cuáles son sus líneas de investigación futura en el campo de la ingeniería del software?, ¿Está preparando ya su siguiente libro?


Mis investigaciones futuras continuarán los mismos hilos de mi investigación pasada: Estoy en busca de mejores métodos de control de calidad, mejores herramientas de cálculo y recojo datos cuantitativos fiables sobre la productividad y la calidad.
Imprimir Enviar a un amigo
Aventia © 2010  ·  Aviso legal