Por qué los requisitos

Nadie duda de que los cimientos son importantes. Por supuesto, se puede construir un edificio sin cimientos, siempre que ese edificio sea una pequeña cabaña de madera o siempre que no nos importe que se derrumbe mientras lo construimos. En cualquier otro caso, necesitaremos una base consistente sobre la que levantar nuestra construcción.

Los cimientos no son importantes sólo en la arquitectura. Desde los años 70 se sabe que el coste de reparar un defecto una vez entregado el producto software es entre 60 y 100 veces superior al coste que hubiera representado el mismo cambio durante las fases tempranas del proyecto. Este hecho, verificado de forma independiente y empírica por Fagan (Fagan, 1997), Boehm (Boehm, 1977) y Daly (Daly, 1977), confirma la necesidad de un enfoque de calidad en las primeras fases del proyecto, relacionadas generalmente con la obtención y especificación de los requisitos del sistema.

Es la economía, estúpido

Aunque las tareas relativas a ingeniería de requisitos suponen entre el 10 y el 15 por ciento del coste medio del desarrollo de un sistema, las consecuencias de una captura de requisitos defectuosa pueden tener un impacto extremadamente alto. El coste de corregir un error es proporcional al tiempo que permanece sin ser detectado: modificar un requisito apenas requiere editar una o dos líneas en lenguaje natural; alterar el diseño implica revisar las especificaciones y comprobar las ramificaciones de los nuevos requisitos; modificar el código significa malgastar el tiempo de los programadores y la realización de cambios que podrían desestabilizar el diseño.

Existen multitud de estudios que demuestran la incidencia directa de las tareas de ingeniería de requisitos en la calidad final del software desarrollado (Bernárdez, 2003). En los años 80, De Marco y Filkelstein estudiaron las causas de los errores encontrados en los sistemas software, encontrando que sólo el 7% de los errores se producía en la fase de implementación, mientras que el 56% del total tenía su origen en la fase de ingeniería de requisitos.

En 1993, durante una investigación sobre la seguridad en los sistemas de control de las sondas espaciales Galileo y Voyager, Robin R. Lutz concluyó (Lutz, 1993) que una de las principales causas de errores era la existencia de requisitos incorrectos, no documentados o desconocidos.

El coste de omitir la ingeniería de requisitos es alto. No sólo porque los sistemas puedan fallar, sino porque pueden no aprovecharse correctamente o resultar bastante más caros de lo estrictamente necesario: estudios sobre sistemas bancarios muestran que los usuarios sólo utilizan el 30 por ciento de las funciones proporcionadas (Eason, 1988). Las clásicas historias sobre fallos catastróficos y espectaculares apuntan a menudo a errores en las especificaciones de requisitos, o al simple hecho de no haber llevado a cabo ningún intento serio por capturar las necesidades de los usuarios. ¿Se trata simplemente por ello de un problema de motivación y educación? Aunque no resulten tan espectaculares como los desastres, muchos sistemas han sido desarrollados satisfactoriamente, y hoy en día la mayoría de empresas dispone de sistemas automáticos para gestionar partes de su negocio.

Caminar sobre el agua

La verdadera clave del problema hay que buscarla en el cambio. Si las organizaciones mantuvieran siempre los mismos procedimientos y el mundo permaneciera inalterable, la gestión de los requisitos sería muy sencilla, aunque de hecho no lo es: los directivos necesitan mejorar las prácticas de la organización, los gobiernos cambian los impuestos, las empresas necesitan responder a los desafíos de la competencia… La consecuencia más inmediata de esto es que rara vez se puede decir que los requisitos están terminados, así que los desarrolladores están condenados a disparar a un objetivo en movimiento.

En 1996, el ESI (Instituto Europeo del Software, European Software Institute), publicó los resultados de una encuesta realizada a empresas europeas en el marco del proyecto ESPITI (European Software Process Improvement Training Initiative). Según las conclusiones del estudio posterior, los ingenieros de software encuentran las mayores dificultades durante la especificación y la gestión de requisitos. El resto de las fases de desarrollo presentaban, en la mayoría de los casos, problemas menores poco significativos.

La ingeniería de requisitos nos ayuda a construir cimientos sólidos para nuestro software, enfocándose en un área fundamental: la definición de lo que se desea desarrollar. Para ello, nos permite diseñar especificaciones concretas que describan con claridad, sin ambigüedades, de forma consistente y compacta las necesidades de los promotores de un sistema. Una especificación correcta de requisitos formará una base sólida sobre la que podamos levantar un edificio con garantías. Según G. Ñistal, “la calidad no puede implementarse al final del desarrollo o en las etapas finales de los procesos de desarrollo sino que es una característica intrínseca al propio producto. La carrera de la calidad debe iniciarse en las especificaciones de los productos, continuando en las fases posteriores…” (Ñistal, 1999).

La ingeniería de requisitos permite asimismo gestionar las necesidades del proyecto de forma estructurada, mejora la capacidad de realizar una planificación temporal del proyecto, disminuye los costes y retrasos del proyecto, y en general incrementa la calidad del software, facilita la comunicación entre el equipo y evita rechazos por parte de los usuarios finales.

Invertir en los cimientos al principio ahorrará dinero más tarde, aunque esta tarea no está exenta de problemas: por un lado, los usuarios tienden a descubrir nuevos requisitos justo cuando el analista piensa que tiene todo cuanto necesita. Por otro lado, está el “problema del mundo en movimiento”, comentado con anterioridad. Todo lo que el analista puede hacer es intentar obtener la mejor fotografía posible del mundo cuando realiza la captura de requisitos, tratar de anticipar el futuro y diseñar software que sea flexible y pueda adaptarse a los cambios. Aunque como recuerda Alistair Sutcliffe en (Sutcliffe, 2002), anticipar el futuro sea un arte oscuro.

Referencias

Algunos artículos interesantes que he citado:

Bernárdez, B. (2003). Una Aproximación Empírica a la Verificación de Especificaciones de Requisitos para Sistemas de Información. Sevilla. Universidad de Sevilla.

Boehm, B. W. (1977). Some Experience with Automated Aids to the Design of Large-Scale Reliable software. IEEE Transactions on Software Engineering-
Daly, E. (1977). Management of Software Development. IEEE Transactions on Software Engineering.

Fagan, M. (1997). Design and Code Inspections and Process Control in the Development of Programs. IBM.

Lutz, R. R. (1993). Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. Proceedings of IEEE International Symposium on Requirements Engineering.

Ñistal, G. (1999). Calidad del software, punto de vista y experiencias de la Administración Pública. Novática (137), 50-53.

Sutcliffe, A. (2002). User-centred requirements engineering. Springer.

Leave a Reply

Your email address will not be published. Required fields are marked *