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
- PMI - Project Management Institute. PMI’s Pulse of the Profession: Requirements Management - A Core Competency for Project and Program Success, 2014.
- C. Jones. Software Defects Origins and Removal Methods, 2012.
- C. Jones, O. Bonsignour. The Economics of Software Quality. Addison-Wesley, 2012.
- K. Pohl, C. Rupp. Requirements Engineering Fundamentals. Rocky Nook Computing, 2011.
- D. Leffingwell. “Calculating the Return on Investment from More Effective Requirements Management”. American Programmer 10(4); 13-16; 1997.
- B. Boehm & V. Basili, V. “Software Defect Reduction Top 10 List”. Computer 34(1). IEEE, 2001.
- F. Brooks. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995.
