La Importancia de la Ingeniería de Requerimientos

La ingeniería de requerimientos es una de las disciplinas fundamentales de la ingeniería de software y proporciona información para la mayoría de las demás disciplinas. Este artículo presenta resultados de investigaciones que fundamentan de manera cuantitativa esta cuestión. El propósito es demostrar las consecuencias del descuido de la disciplina de requerimientos: retrasos en el cronograma y costo adicional, nivel alto de defectos en el software y principalmente la entrega de un software que no satisface las necesidades del cliente.  

Fallos famosos

Para ilustrar, a continuación se muestran casos famosos de fallos en proyectos de software relacionados con algún tipo de discapacidad en el ejercicio de la ingeniería de requerimientos.

La sonda espacial Mars Climate Orbiter (MCO)

La MCO fue una sonda espacial cuyo objetivo principal era estudiar el clima de Marte. Fue lanzada en diciembre de 1998, alcanzando Marte nueve meses y medio después. Al entrar en la órbita de Marte, la sonda fue destruida en la atmósfera debido a un error de cálculo en la maniobra. El error fue causado porque el software responsable del cálculo de ruta de entrada esperaba datos usando el sistema de medidas imperial (libras fuerza) y recibió datos en sistema métrico universal (newtons). No se sabe si la NASA proporcionó la especificación equivocada al proveedor que desarrolló el software o si hubo una falla del proveedor en el levantamiento de requerimientos.

Misil antibalístico Patriot

Durante la Guerra del Golfo, los Estados Unidos usaron un sistema de defensa con misiles antibalísticos llamado Patriot. El 25 de febrero de 1991 este sistema falló y no interceptó el misil Scud lanzado por Irak que mató a 28 militares y lesionó otros 98.

La raíz de la falla fue que el software original del sistema utilizaba datos de las señales del radar para calcular la ruta del Patriot y trabajaba con una precisión de fracciones por segundo. Para hacer frente a misiles de más alta velocidad, se creó una subrutina para manejar el tiempo con mejor precisión (más decimales). Sin embargo, esta subrutina no fue aplicada a todas las partes necesarias del software lo que generó una acumulación de fallas de precisión; y después de cierto tiempo, el sistema se quedaba ineficaz. No fue sólo un fallo de programación, fue también un fallo de evaluación en el impacto del cambio.

Cohete Ariane 501

El 1996, el cohete Ariane 501 fue lanzado y unos 37 segundos después del despegue, se desvió del curso esperado para después explotar. Fue el primer lanzamiento de la serie Ariane 5. La pérdida del cohete y su carga ascendieron a una pérdida de más de 370 millones de dólares. La comisión de investigación señaló que la falla había estado en el sistema de referencia inercial, el cual había sido reutilizado de la serie Ariane 4. El problema fue que el Ariane 5 estaba diseñado para transportar más carga, lo que implica otros estándares de trayectoria y velocidad diferentes, y esto no se tomó en cuenta al realizar el diseño y pruebas pertinentes.

Archivo Virtual FBI

A principios del 2000, el FBI comenzó el desarrollo de un software llamado Virtual Case File (VCF) que permitiría el intercambio de información de casos entre los agentes. Originalmente se estimó que el desarrollo tomaría 3 años. Después de la tragedia del 11 de septiembre de 2001 el FBI recibió fuertes críticas por no anticipar el ataque; las evidencias estaban expuestas, el error fue no enlazarlas entre sí. Ante esto, se decidió aumentar la prioridad del VCF y extender su alcance. Cinco años y 170 millones de dólares después, el sistema no había podido ser terminado y se canceló su desarrollo. La investigación a cargo determinó que las principales causas de fracaso fueron:

• Cambios frecuentes en los requerimientos. El proveedor alegó que el FBI adoptó la filosofía de trabajo de: "Yo sé lo que quiero después de ver el producto."

• Alta rotación de gestión (también contribuyó a los cambios frecuentes).

• Aumento descontrolado del alcance, con requerimientos agregados incluso cuando el proyecto ya estaba retrasado.

El principal motivo de fracaso

De acuerdo con cifras del Project Management Institute (PMI) [1], el 47% del fracaso de los proyectos es causado por una deficiencia en el ejercicio de la ingeniería de requerimientos. Algunos casos comunes:

• El producto se entrega sin cumplir con los requerimientos necesarios, sin identificar varios de ellos.

• La entrega final es un producto que no satisface al cliente, aunque a tiempo y dentro del presupuesto.

• El proyecto incorpora requerimientos que no deben estar en el alcance.

• La estimación de costo/esfuerzo se hace en base a un alcance equivocado ya que no considera algunas áreas funcionales y procesos de negocio.

• Fallas de comunicación sobre requisitos, lo que resulta en la entrega de un producto defectuoso.

• Cambios innecesarios debido a la falta de atención por comprender correctamente las necesidades del cliente al principio.

Una de las principales causas de defectos

Los defectos pueden surgir en cualquier etapa del ciclo de vida del proyecto, siendo el más común aquellos insertados durante la construcción, donde el producto construido tiene un comportamiento diferente al especificado.

Asimismo, un número  significativo de defectos se origina a partir de los requerimientos.  Pero, ¿La calidad no es cumplir con los requerimientos? ¿Cómo sería posible ello? Simple, basta que la especificación no represente correctamente las necesidades del usuario.

Según, Capers Jones [2], 1 de cada 5 posibles defectos se origina en los requerimientos, y estos pueden ser hasta el 60% del total de errores en el proyecto según explica Pohl [4]. La problemática es que estos sólo se detectan en etapas avanzadas del proyecto, a menudo cuando se aprueba el producto. Por otro lado, Leffingwell [5] acota que en proyectos complejos la fuente más común de errores son los requerimientos. Esto último se refleja en los resultados mostrados por Jones y Bonsignour [3] que se capturan en la tabla 1 donde se muestra la tasa potencial de defectos por punto de función segregados por la fuente del defecto y estratificado de acuerdo al tamaño del sistema.

Tabla 1. Defectos en potencial por tamaño de sistema y origen.

Los defectos originados en requerimientos son más difíciles de eliminar por métodos tradicionales: pruebas y análisis estático. Esto se debe a que cuando se aprueba la especificación con un requerimiento defectuoso, los casos de prueba son elaborados a partir del comportamiento equivocado.

Adicionalmente, los cambios en requerimientos tienden a una densidad de defectos mayor, debido a que típicamente son tratados a toda prisa. Y son más difíciles de eliminar porque “saltan” el control de calidad del proyecto. Por ejemplo, un crecimiento del 10% en el alcance del proyecto implica un aumento del 12% en el número de defectos.

El costo de reparación de los defectos

La industria del software tiene un gran potencial para explotar las ganancias de eficiencia. Según Boehm [6] del 40 al 50% del esfuerzo en los proyectos de software se gasta en la corrección de defectos. Uno de los factores que contribuyen para esta ineficiencia es que al corregir un defecto existe un 20-50% de posibilidades de introducir otro error al software [7].

Pohl [4] sostiene que la mayoría de los errores originados en los requerimientos se detecta en las etapas avanzadas del proyecto. Él afirma que una parte significativa de estos errores se identifica durante la validación por el cliente. El esfuerzo de encontrar y corregir un defecto después de la entrega, suele costar a menudo 100 veces más que corregirlo cuando todavía se está desarrollando los requerimientos. Como se observó en los casos citados, los errores detectados con el software en operación pueden causar daños en varios órdenes de magnitud mayor al costo de corrección del defecto.

El objetivo es desarrollar el producto correcto en el primer intento. De esta manera, se reducen los errores en las primeras etapas del proyecto en donde se puede mitigar con mayor intensidad la reanudación. El método de ensayo y error, además de ser más caro y demorado, crea insatisfacción en el cliente. Por lo que se busca es evolucionar en la calidad del trabajo con requerimientos para lograr un impacto positivo en el costo, el tiempo y la satisfacción del proyecto.

Referencias

1. PMI - Project Management Institute. PMI’s Pulse of the Profession: Requirements Management - A Core Competency for Project and Program Success, 2014.

2. C. Jones. Software Defects Origins and Removal Methods, 2012.

3. C. Jones, O. Bonsignour. The Economics of Software Quality. Addison-Wesley, 2012.

4. K. Pohl, C. Rupp. Requirements Engineering Fundamentals. Rocky Nook Computing, 2011.

5. D. Leffingwell. “Calculating the Return on Investment from More Effective Requirements Management”. American Programmer 10(4); 13-16; 1997.

6. B. Boehm & V. Basili, V. “Software Defect Reduction Top  10 List”. Computer 34(1). IEEE, 2001.

7. F. Brooks. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995.