ENTREVISTA INFODEFENSA.COM: Ignacio Núñez Ladeveze, director de operaciones de Polar Consultores: "Los fallos de software ocasionan pérdidas económicas en sí, pero también derivadas de los retrasos"

15/12/2008 Por A. V. Suárez (Infodefensa.com) - Un fallo de software puede ocasionar pérdidas económicas y de clientes importantes. En los últimos años, se han conocido casos en los que la puesta en marcha de sistemas informáticos sin pruebas de validación y verificación han comprometido, incluso, la integridad de las personas.

Desde hace 18 años, una empresa española Polar Consutores, trabaja con herramientas cuyo objetivo es evitar estos errores y sus consecuencias mediante el desarrollo de pruebas de sistemas críticos (en los que un fallo operativo provoca pérdidas importantes) y complejos (cuyo esfuerzo de desarrollo supera los 75 hombres por año).

En el ámbito de la Defensa y Seguridad, esta compañía ha trabajado con empresas como Indra e Isdefe y tiene en el campo del tráfico aéreo su gran escuela. Ignacio Núñez Ladeveze, director de operaciones, explica a Infodefensa.com en qué consiste el funcionamiento de estas herramientas.

¿Cuál es el problema que habían identificado para pensar en esta solución?

Empezamos con pruebas de sistemas de software en sistemas de control de tráfico aéreo. En temas de seguridad es el paradigma, porque si no se cumple con el safety (que no security) no sale un avión ni se pone en marcha el aeropuerto. Además, ese paradigma cambia, ahora la seguridad aérea no sólo abarca el control del tráfico por radar, incluye que el avión no encuentre cualquier situación extraña, que no se haya previsto y corra peligro. Desde 2000, hay que mejorar la capacidad y el safety.

¿Cuáles han sido las aplicaciones en Defensa y Seguridad?

Esto es está dentro de un entorno de las tecnologías duales, aplicables tanto a Defensa como al transporte aéreo en este caso. Nosotros no trabajamos directamente con Defensa, porque no tenemos la definición de seguridad NATO, pero desde hace 15 años estamos habituados a los procedimientos y la normativa de calidad más exigente.

¿Con qué empresas han trabajado en el ámbito de la Defensa y Seguridad?

En el ámbito de Defensa, con Indra e Isdefe. En otros ámbito trabajamos mucho con empresas de ingeniería, en el entorno aeronáutico con AENA, también con la banca o en sistemas de identificación personal en Argentina.

¿Se han cuantificado los ahorros por la utilización de esta herramienta?

En el campo aeronáutico, un claro ejemplo fue el Ariane 5 en el que se dio por probado un programa y el resultado fue que se estrelló. La segunda sonda que fue a Marte también tuvo un fallo de software, a priori absolutamente trivial, simplemente que se no había cambiado los parámetros de pies a metros y también se estrelló. En áreas como la telefonía, hace relativamente poco Vodafone también tuvo un fallo que se quedó sin cobertura total durante cierto tiempo y también fue un fallo de software. No soy el más indicado para evaluar las cantidades, pero no es en sí la pérdida económica del proyecto, que sería fácil de saber, sino también las pérdidas derivadas de los retrasos del propio programa, por ejemplo.

¿Estos casos tan sonados han hecho que las empresas hayan tomado conciencia de la necesidad de herramientas de control de software?

Yo creo que sí, es un tema que está cada vez más presente en los congresos y en las empresas. Hace diez años éramos los únicos que nos dedicábamos a esto en España, y ahora cada vez hay más compañías que se dedican a pruebas de software.

¿Ustedes trabajan sólo para el mercado español?

No, nosotros también trabajamos mucho, por ejemplo, en Argentina. Muchos de nuestros clientes finales son extranjeros, como la dirección de aviación civil alemana, siendo nuestro cliente directo Indra. También Eurocontrol, el día 12 de diciembre se puso en marcha el sistema ACC Maastricht. Son proyectos donde una puesta en operación es importante porque el desarrollo dura seis años y normalmente suele haber retrasos.

¿Cuándo se actúa, al final del proyecto o se trata de un proceso?

Es un proceso, empieza desde el comienzo del proyecto. Los niveles de pruebas son muchos en un desarrollo software. En primer lugar se realizan pruebas unitarias, que son los módulos de los que está compuesto el sistema de software, luego se prueban los módulos formados por los componentes unitarios definidos, más tarde está el escalón de subsistemas y, finalmente, las pruebas a nivel de sistemas.

En función de los requisitos técnicos que tenga el proyecto, en cuanto a la calidad y al calendario, el plan de pruebas hay que realizarlo durante los tres primeros meses del desarrollo. Otra cosa son los procedimientos de cómo se realizan las pruebas de unos y otros requisitos. Las pruebas generales del sistema sí son al final, en los dos últimos años... el problema es que todos los retrasos del sistema también se acumulan para las pruebas, hay que absorber los retrasos. Por ejemplo, sólo en el programa ACC Maastricht se han realizado hasta 20.000 pruebas distintas, 20.000 procedimientos distintos para un total de 6.000 requisitos técnicos.