El porqué del análisis de requerimientos

Imagen Requerimiento por  Iván Orpí  (CC BY-NC-SA)

En 1986 Alfred Spector, presidente de Transarc Corporation, comparaba 2 procesos de ingeniería: la construcción de puentes y el desarrollo de software. Su hipótesis era que los puentes se construían cumpliendo con planificación y presupuesto, y sin venirse abajo; sin embargo el desarrollo de software no solo incumplía plazos y presupuesto sino que además, el software, se “caía”.

Quizás es una visión muy extrema de las cosas. Los puentes a veces se caen, y la mayoría de veces las obras ni cumplen plazos ni presupuesto, pero lo cierto es que el nivel de detalle con el  que se diseña un puente es extremo comparado con el de los sistemas de información; además, su diseño es estable, y la posibilidad de que cambien las especificaciones es casi nula. Por romper una lanza en favor de la ingeniería del software, diría que la construcción de puentes tiene una experiencia acumulada de muchísimos siglos, y de pocos años en la ingeniería del software.

A la hora de proporcionar soluciones que atiendan a un problema o necesidad de negocio, la mayoría de proyectos de software fracasan en un aspecto que no tiene nada de técnico: la fase de análisis de requerimientos. Veamos el porqué del análisis de requerimientos.

Algunos datos

El informe “The Chaos Report” de 1995 de de Standish Group destacaba que sólo un 16% de proyectos finalizaban con éxito; el resto eran proyectos fracasados o deficientes (se ponían en producción pero no cumplían con necesidades, calendario y dotación presupuestaria). Determinaba que el principal factor de cancelación o deficiencia tenía que ver con los requerimientos. El mismo informe de 2014 presenta una notable mejoría con un 39% de proyectos finalizados con éxito, cosa que evidencia que vamos aprendiendo y mejorando, y que diseñamos sistemas un poco mejor.

En 1996 el artículo «Software Quality at Top Speed» de Steve McConnell, autor, columnista, CEO y Jefe de Enginiería del Software en Construx Software, muestra cómo los defectos tienden a ser más costosos en su resolución así como se producen en etapas más tempranas del ciclo de vida del desarrollo del software, y así lo ratifica en 2012 el artículo «Software Quality Metrics: Three Harmful Metrics and Two Helpful Metrics» de Capers Jones, Vice Presidente y CTO de Namcook Analytics LLC, donde establece que ese coste de resolución en la puesta en producción se ve multiplicado por 20 respecto del coste si ese defecto o carencia se detecta durante la fase de análisis.

El estudio “La Crisis del Software” de Jesús Zavala Ruiz de 2003 proporciona un dato que pone los pelos de punta, pues señala que el origen de los errores de software se encuentra en el 56% de los casos en la fase de estudio y análisis, es decir, en los requerimientos.

Un estudio del 2008 de Keith Ellis, Vicepresidente de IAG Consulting, publicado en la Busuiness Analysis Times, concluye que aquellas empresas con una pobre capacidad de análisis de negocio triplican los proyectos fallidos con respecto de los que llegan a buen puerto. Además, en estas compañías siempre confluyen 2 de los siguientes factores:

  1. Prácticamente doblan el tiempo de entrega.
  2. Tienen un exceso de costes de un 160% sobre el presupuesto.
  3. Entregan un 70% menos de la funcionalidad.

Creo que queda patente que es de vital importancia prestar especial atención a la fase de requerimientos por dos razones:

  1. Es donde se comenten la mayor cantidad de errores u omisiones.
  2. Es donde existe un menor coste de detección y corrección.

La cruda realidad

Por desgracia es habitual que “el cliente” nos diga que quiere pintar su casa, pero nada más; y empiezan a surgirte preguntas:

  • ¿toda blanca o de colores y, en tal caso, qué colores?
  • ¿qué colores concretos aplican a qué estancias?
  • ¿todas las paredes de una misma estancia han de tener el mismo color o hay alguna de ellas que se quiera en un color o tonalidad diferente?
  • ¿los techos deben ir también pintados? Si así fuese, ¿en blanco o con un degradado del color de las paredes?
  • ¿debemos eliminar el ya trasnochado gotelé o pintamos sobre él?

Y al final, ¿qué ocurre? Pues que te pones a pintar porque el cliente “no sabe o no contesta”; vas tomando decisiones por tu cuenta y riesgo, y cuando llega el día de mostrar al cliente su casa recién pintada un “esto no es lo que yo esperaba” es lo que obtienes por respuesta. En pocas palabras, para hacer algo hay que saber qué se debe hacer, qué es lo que se necesita, y cuanto mayor detalle tengamos, más precisos seremos en la construcción de la solución final.

Lo primero es lo primero

El análisis de requisitos es el primer paso en el proceso del desarrollo del software (o debería) y, por lo ende, resulta de vital importancia ya que asienta la base del resto de etapas en dicho proceso. Por ello, la obtención de un documento de especificación de requisitos del sistema (System Requirement Specification) es primordial, y debe de ser el eje de rotación de todo proceso de ingeniería del software.

Un requerimiento es una condición o capacidad requerida por una organización para resolver un problema o alcanzar un objetivoIEEE 610.12-1990

, establece qué debe hacer el sistema, pero no cómo hacerlo, e

incluye, pero no se limita, a condiciones o capacidades pasadas, presentes o futuras en una organizaciónBABOK Guide V2

Los requisitos juegan un papel importante en la ingeniería de sistemas, ya que:

  1. Forman la base de la arquitectura del sistema y las actividades de diseño.
  2. Forman la base para las actividades de verificación.
  3. Actúan como punto de referencia para la validación y la aceptación de las partes interesadas.
  4. Proporcionan un medio de comunicación entre los diferentes técnicos que interactúan a lo largo del proyecto.

Así pues, un requerimiento, o mejor dicho, el conjunto de requerimientos que conforman el SRS, nos sirve para que un cliente describa claramente lo que quiere, que el proveedor entienda lo que ese cliente requiere, que se eviten vueltas atrás en la etapa de diseño o de desarrollo (por falta de entendimiento) y que se tenga una base sobre la que probar y validar el producto final.

Entonces, ¿qué está ocurriendo?

Las prisas o las limitaciones presupuestarias hacen que nos centremos en lo que es más visible y que evidencia un progreso claro en los proyectos: el diseño (con suerte) y la construcción, dejándonos en el tintero fases previas que son el fundamento de un buen diseño y construcción. La fase de análisis requiere de tiempo, y el tiempo tiene un coste, y ese coste “no entendido” por la organización es el que no se quiere pagar. Tampoco se es consciente del efecto que, a la larga, tiene no invertir en el análisis, porque al final acabas gastando mucho más en corregir y evolucionar el sistema.

Formamos ingenieros fantásticos en las universidades y al salir de ellas sabemos muchas cosas, pero no sabemos nada o casi nada sobre el ‘Business Analysis’. Preguntaros cuántas prácticas de programación habéis hecho y cuántas de toma de requerimientos y, si habéis hecho alguna de toma de requerimientos, ¿qué tiempo se le ha dedicado a la práctica en comparación con otras?

Conclusión

Por lo expuesto, creo que queda patente la importancia de ponerle cariño (y presupuesto) a la toma de requerimientos. Si no lo hacemos el proyecto, en el mejor de los casos, acabará costando mucho más que si le hubiésemos prestado atención a esta fase primordial desde el principio, y no se podrá disfrutar del sistema plenamente hasta pasado mucho tiempo. Además, los errores y omisiones en fases preliminares se arrastran a lo largo de todo el proyecto, y suponen el mayor coste de reparación con respecto de errores u omisiones en fases más tardías.

Un comentario

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.