La Ingeniería del Software basada en Valor


Javier Garzás y Mario Piattini

En general, la historia de la ingeniería del software está repleta de ejemplos en los cuales una vez aparecida una técnica o buena práctica, ésta ha sido un fracaso al aplicarla, pero un éxito a la hora de ser venerada por el sector (Boehm, 2006), provocando movimientos que (Davis, 2004) describe como similares a los de los “lemmings”, donde alguien crea un concepto y muchos otros le siguen… aunque finalmente todos acaben perdidos.

Recurrentemente nos preguntamos cuál es la aportación real de las diferentes propuestas que van apareciendo, es decir, qué valor aporta una determinada técnica o buena práctica. Este es precisamente el enfoque de una nueva orientación en la ingeniería del software denominada “Ingeniería del Software Basada en Valor”(o ISBV de Value-Based Software Engineering). La ISBV pretende orientar las propuestas y soluciones basándose en la maximización del valor aportado, cualquier decisión de construcción (o reingeniería) de un sistema software, o incluso cualquier decisión de diseño o metodológica debería estar guiada por su “valor”.

En la actualidad, la mayoría de las prácticas de ingeniería del software se basan en un enfoque de valor neutral, es decir, cada requisito, caso de uso, objeto, prueba, etc., se trata con igual importancia, y si bien en los proyectos se hace un seguimiento de los costes no sucede de igual manera con el valor que aporta al negocio cada uno de los elementos del desarrollo software. Tiempo atrás, cuando las decisiones que afectaban al software tenían relativamente poca influencia en costes, planificación y valor, una aproximación de valor neutral podía ser razonable, pero en la actualidad estas decisiones tienen demasiada repercusión (Boehm & Huang, 2003).

La pobre gestión económica en el área de la ingeniería es uno de los aspectos que la ISBV aspira a mejorar. Y de hecho, recientemente se ha abierto un importante debate entorno a los aspectos económicos del software, curiosamente después de tantos años de estudio de la disciplina. Como ejemplo (Harrison, 2005) comenta como en su experiencia: “según pasa el tiempo, estoy más convencido de que hay una necesidad real para el desarrollador de entender y apreciar el contexto económico en el que opera su organización”. En este sentido los profesionales del software se encuentran frecuentemente desorientados, sin poder estimar el valor que aporta cada desarrollo, y careciendo de la visión global necesaria supone el software para la supervivencia de su organización. Esto se une a la inmadurez del software para integrarse con el resto de disciplinas de la empresa, como pueden ser las finanzas, el marketing o los recursos humanos.

1. El concepto de valor en ingeniería del software

El valor que aporta un sistema a sus usuarios no se define ni por su tamaño, ni por el número de funcionalidades que aporta. Fácilmente se puede imaginar un sistema enorme y que facilite una gran cantidad de funcionalidades que no son usadas por nadie, con lo que no aportará ningún valor. Por otro lado, una pequeña funcionalidad puede ahorrar diariamente horas de trabajo a mucha gente. De este modo, un sistema aporta más “valor” a sus usuarios si proporciona mayores beneficios, ya sea en términos de retorno de inversión (ROI), beneficios sociales, disminución en los costes de gestión, ventajas estratégicas, o cualquier otro aspecto. Como puede suponerse, la cuantificación de todos estos tipos de beneficios es algo complejo.

2. Áreas de la Ingeniería del Software Basada en Valor

(Boehm, 2005) introduce una agenda que pretende integrar las consideraciones de “valor” dentro del conjunto de principios y prácticas existentes. Para organizar todas las aportaciones, y procurar que sean compatibles de manera que se potencien entre ellas, se definieron distintas áreas de trabajo que las agrupasen:

  • Ingeniería de requisitos basada en valor, para la identificación de principios y prácticas respecto al valor de los requisitos.
  • Arquitectura, diseño y desarrollo basado en valor, para reconciliar los objetivos de negocio y del sistema, con la arquitectura y construcción del software.
  • Validación y verificación basada en valor, para desarrollar técnicas de verificación y validación del software respecto a objetivos de valor y su priorización.
  • Control y planificación basada en valor, para evolucionar las técnicas más tradicionales sobre planificación, coste y control y que incluyan el concepto del valor que aportan.
  • Gestión de riesgos basada en valor, para priorizar, mitigar, identificar, y analizar riesgos desde la perspectiva del impacto que pueden tener en el valor.
  • Gestión de la calidad basada en valor, para la priorización de los factores de calidad deseables con respecto al valor que aportan.
  • Gestión de personal basada en valor, para la gestión del equipo y recursos humanos en pro de valor.

3. Conclusiones

Una nueva orientación de la ingeniería del software está emergiendo. Se basa en que no todos los elementos del desarrollo software tienen el mismo valor relativo, sino que existen partes que aportan más valor que otras. La ingeniería del software basada en valor tiene por objetivo elaborar técnicas y prácticas que formalicen y cuantifiquen cuánto aporta cada elemento a cada uno de los actores del sistema.

La puesta en marcha e impulso de un proyecto software, ya sea su creación, mantenimiento, o reingeniería, está directamente relacionada con la percepción que los actores tienen sobre los beneficios que aportará. Por ejemplo, la inversión en la creación de un sistema software se basa en la creencia de que el producto que se desarrolla aportará beneficios. Un proyecto no se pondrá en marcha si la dirección de las organizaciones no perciben claramente los beneficios que el producto software les aportará.
El concepto de “valor” suele estar fuertemente ligado al beneficio económico. Sin embargo, se trata de un concepto más amplio, que abarca desde ventajas en el mercado a beneficios sociales. El reto que se presenta es el estudio de todas estas variables y su influencia en los diferentes interesados en el sistema.
Como se ha visto a lo largo de este artículo, la ISBV es una rama que está en investigación, joven y a la que aún le queda un largo camino por recorrer para llegar a un nivel de madurez similar al de otras áreas de la ingeniería del software. Sin embargo, ya se ha definido una hoja de ruta, y han aparecido algunas propuestas que van ampliando poco a poco este nuevo enfoque.

4. Referencias

  • Boehm, B. (2005). Value-Based Software Engineering: Overview and Agenda. In Value-Based Software Engineering (pp. 3-14): Springer.
  • Boehm, B. (2006). A View of 20th and 21st Century Software Engineering. Paper presented at the International Conference on Software Engineering (ICSE), Shanghai, China
  • Boehm, B., & Huang, L. G. (2003). Value-Based Software Engineering : A Case Study. IEE Computer Society, 36(3), 33-41.
  • Davis, A. (2004). Great Software Debates: Wiley-IEEE Computer Society Press.
  • Harrison, W. (2005). What Do Software Developers Need to Know about Business? IEEE Software, 22(5), 5-7.